Transcripted Summary
Now that the Planner agent has analyzed our Inflectra SpiraPlan requirements and generated our prioritized BDD scenarios, it's time to shift from planning to execution. This is where the Generator agent steps up. The Generator's sole responsibility is to translate our strategic markdown or Gherkin plans directly into production-ready Playwright automation test files.
# The Page Object Foundation
Before we let AI generate anything, we need to understand the foundation, which are the page object files: login page and registration form page.
Let's start with the login page. With this, you can see that this is a complete reference implementation. We have declared our locators at the top, then defined the locators with values using Playwright's getByRole strategy for the username, password, and login button. Under the constructor, we have a public login method that takes care of the complete flow. The AI agent will read this file to understand the coding standards.
Next is the registration page, which has 49 lines of code. Here, we have mapped out key locators for our student registration form in the constructor, which includes the text fields for first name, last name, and email, as well as our validation error locators. Some of the methods are set first name and click submit button.
# A Deliberate Naming Convention Test
At this moment, there are five test spec files: two files for login and three files for the registration form.
Now, take a close look at the file extensions in our project tree. You will notice something I did on purpose. The login suite uses the .spec.ts naming convention while our registration suite uses the .test.ts extension. Under the hood, the Playwright configuration is designed to read both extensions out of the box. There is no difference in execution between them — it comes down to your team's preference.
Think about it this way. In our industry, spec is short for specification, which represents a requirement or a blueprint of how a system should behave. On the other hand, test is the execution and evaluation we perform, like a full end-to-end user flow. Since we are writing functional scripts to execute test scenarios, .test.ts makes the most sense. Personally, I prefer .test.ts for clarity.
But here is why we have this mixed setup for our course: we want to put our Generator agent to the intelligence test. We want to see if AI can analyze the structure of our target directory, respect our naming conventions, and output our new registration test using .test.ts rather than blindly falling back to the default .spec.ts.
# Prompting the Generator
Let me go back to VS Code. This is the pre-existing project, and with it we're going to see how the Planner agent discovered additional test coverage — required fields and interactions we have not written methods for yet. We are going to tell the Generator agent to analyze these files, discover what is missing based on the new tests, then add those new locators and methods into our page object files while creating our test.
We are going to select a P0 scenario from our test plan. But remember the rule of our five-star kitchen framework: we do not allow AI to guess or use unstable locators. It must read our Page Object Model file and use the defined methods. We have already established this inside our page object file.
Let's go to the BDD file real quick. How about we pick the first scenario, P0. Now with this, we see that it shows the scenario is successful submission with all required fields completed. It's short and gets to the point: given I have entered Jane as the first name, and I have entered Doe as the last name, and I have selected Male as the gender, and I have checked Java under programming language, when I click the submit button, then the "thanks for submitting this form" confirmation dialog is displayed.
Okay. So watch my screen as I copy and paste this request for the Generator agent. It's always good to create a new chat or clear the conversation if the request is different or does not involve the same subject. This involves a similar subject, but let's go ahead and clear it. It's similar because we're still working with the test agents — the other one was Planner, this is Generator. I'm going to clear it, then paste it.
It says: use the Playwright Test MCP Generator agent. Look at the P0 registration scenarios inside our test artifacts directory. Then create a test for scenario 001. Analyze our existing Page Object Model files located at the page objects folder directory. Generate Playwright test files using the same naming convention as existing files under the relevant test folder.
Strict compliance rules:
- Identify any form elements required by the test scenario that do not exist in our page object files. Dynamically create and append those new locators and methods directly into the relevant file.
- Always use existing files for reference.
- Do not write raw selectors or element handles inside the test file. The test spec must exclusively utilize the methods that the page object exposes.
- You must insert the mandatory
// Created By AIaccountability tag as a comment on the very first line of the generated test file and/or generated code.
There's something going on with the chat box, but I'm going to go ahead and press run.
# Verifying the Generated Test
Now the Generator agent is going to work. The summary says: created the P0 scenario 001 test, successful submission with all required fields completed. It shows the test artifact, the page object registration page, and where the test is, which is right here. So let's go to it and see what's inside of the test.
At the top, look what it shows: the tag // Created By AI on line one. It respected our rule and stamped the file with the Created By AI tag. That tells us this file is currently on probation and requires a human-in-the-loop review before it can ever be merged into our repo branch.
Next, let's look at the structure of the test itself. Notice there are zero locators inside this file. The Generator imported our registration page object model, and it called existing methods like set first name.
Let's look at the other test files real quick — the previous ones, like verify page title. And you see how there are no locators inside the test. That's an industry standard of separating the locators in a page object from the test.
So the Generator agent successfully processed our functional scenario. But what happens when things go wrong? When a locator changes, or the framework encounters a failure? To see how the Playwright Test MCP takes care of maintenance, we need to look at our last agent — the Healer agent. We're going to move on to that one in the next session.
Quiz
The quiz for this chapter can be found in 3.4.
