Playwright Test Agents: Can AI Really Write and Fix Your Tests?

A few years ago, automating a login page was fairly straightforward.

You would open the application, inspect the HTML elements, write a Playwright or Selenium script, and run it.

Everything worked fine until someone changed the UI.

Maybe the login button was renamed. Maybe a form field moved. Or perhaps a developer replaced an ordinary HTML input with a custom Angular component.

Suddenly, a test that had been working for months started failing.

The application itself might be perfectly fine. But the automation script no longer knows how to interact with it.

If you've worked with UI automation, you've probably come across situations like this.

Now imagine having an assistant that can explore your application, suggest what should be tested, write the test scripts, and help investigate failures.

That's the idea behind Playwright Test Agents.

Let's understand how they work, using a simple example.

First, what is Playwright?

Before getting into AI agents, let's understand Playwright itself.

Playwright is an open-source browser automation framework developed by Microsoft.

It allows developers and QA engineers to automatically test web applications.

For example, instead of manually opening a website and checking whether login works, you can write a test that:

1. Opens the login page.
2. Enters an email address.
3. Enters a password.
4. Clicks the Sign In button.
5. Checks whether the application displays the expected result.

The browser performs these actions automatically.

Playwright supports Chromium, Firefox, and WebKit, so the same test can be executed across different browser engines.

But there's one challenge.

Someone still needs to decide what to test, write the automation scripts, and maintain them when the application changes.

This is where AI agents become interesting.

What are Playwright Test Agents?

Playwright introduced Test Agents in version 1.56.

Instead of relying entirely on manually written test scripts, these agents help with different stages of the testing process.

There are three main agents:

1. Planner — Decides what to test

The Planner explores your application and prepares a test plan.

2. Generator — Writes the tests

The Generator takes that plan and creates Playwright test scripts.

3. Healer — Helps fix failing tests

The Healer runs tests, investigates failures, and attempts to repair issues in the automation code.

Think of them as three members of a QA team.

One prepares the scenarios, another writes the automation, and the third investigates why something failed.

Of course, they're AI agents, not actual team members. Their output still needs to be reviewed.

Let's take a real-world example

Imagine we're building a customer portal using Angular for the frontend and ASP.NET Core for the backend.

The application has a signup page with four fields:

• Full Name
• Email
• Password
• Confirm Password

There's also a Create Account button.

As a developer, you might test it once with valid information, see that the account was created successfully, and move on.

But what else could go wrong?

What happens if someone enters an invalid email address?

What if the password and confirmation password don't match?

What if the user tries to register with an email address that already exists?

What if someone clicks Create Account without entering anything?

These are basic scenarios, but it's surprisingly easy to miss one when you're focused on delivering a feature.

Let's see how the agents could help.

Step 1: Planner — Let AI prepare the test scenarios

We start by giving the Planner a simple instruction.

For example:

Explore the signup page of my application and create a test plan. Include successful registration, invalid email addresses, empty fields, password mismatch, and duplicate email registration.

The Planner can inspect the application and prepare a Markdown file containing the proposed scenarios.

An example plan might look like this:

Scenario	Expected result
Valid signup details	Account is created
Empty email address	Required-field validation appears
Invalid email format	Email validation error appears
Password mismatch	Password mismatch message appears
Duplicate email	Appropriate error message appears

The actual plan will depend on the application's behaviour and requirements.

Notice something important here.

We didn't start by writing TypeScript code.

We started by explaining what the application should do.

This is useful for beginners because it encourages thinking about test scenarios before automation scripts.

However, the Planner cannot automatically know every business rule. For example, it may not know whether your application requires a minimum password length of 8 or 12 characters unless that information is available.

So review the plan before generating tests.

Step 2: Generator — Turn the plan into Playwright tests

Once the test plan is ready, the Generator can use it to create executable test scripts.

For example, consider this scenario:

A user should not be able to register with an invalid email address.

A Playwright test for that scenario might look like this:

import { test, expect } from '@playwright/test';

test('Invalid email should show an error', async ({ page }) => {

  await page.goto('http://localhost:4200/signup');

  await page.getByLabel('Full Name').fill('John');

  await page.getByLabel('Email').fill('invalid-email');

  await page.getByLabel('Password').fill('Password@123');

  await page.getByLabel('Confirm Password').fill('Password@123');

  await page.getByRole('button', { name: 'Create Account' }).click();

  await expect(
    page.getByText('Please enter a valid email')
  ).toBeVisible();

});

This is an illustrative test. The field labels, page URL, and validation message would need to match your actual application.

If you're new to Playwright, here's what the important lines do.

page.goto() opens a webpage.

getByLabel() finds an input field using its visible label.

fill() enters a value into that field.

getByRole() locates the button.

click() simulates a user clicking it.

expect() checks whether the expected result appears.

In this example, we're checking that the application displays an email validation message.

Without AI, we could write this script manually.

With the Generator, we can ask an agent to create similar scripts based on our test plan.

That doesn't mean we should accept every generated test without checking it. An AI agent could write an assertion that doesn't reflect the intended business behaviour.

Step 3: Healer — What happens when a test breaks?

Now let's imagine something changes in our Angular application.

Originally, our signup button was called:

Create Account

A few weeks later, the design team changes the text to:

Sign Up

The application continues to work for normal users.

But our automated test still searches for a button called Create Account.

await page.getByRole('button', { name: 'Create Account' }).click();

Because the button name has changed, the test may fail.

This is where the Healer becomes useful.

The Healer can execute the failing test, inspect the page, and attempt to identify what changed.

If it determines that the Sign Up button is the correct replacement, it may suggest updating the locator to:

await page.getByRole('button', { name: 'Sign Up' }).click();

It can then rerun the test to check whether the change resolves the failure.

That's a relatively simple example, but it shows why test maintenance is such an important part of automation.

There's an important catch, though.

Suppose registration itself has stopped working because the ASP.NET Core API is returning an HTTP 500 error.

That's a genuine application defect.

We don't want an AI agent to simply remove the failing assertion so that the test passes.

A passing test is only valuable when it's checking the correct behaviour.

The Healer may also skip a test if it believes the functionality is broken, so those outcomes need human review.

How can you try Playwright Test Agents?

If you're a developer working with Angular, React, or ASP.NET Core, you can experiment with these agents using a local web application.

You'll need Node.js, a supported AI coding assistant, and a Playwright project.

First, initialize Playwright if it isn't already installed:

npm init playwright@latest

Follow the installation prompts to configure your test project and install the required browsers.

Next, initialize the Playwright Test Agents.

For VS Code:

npx playwright init-agents --loop=vscode

For Claude Code:

npx playwright init-agents --loop=claude

For Codex:

npx playwright init-agents --loop=codex

These commands add agent definitions to your project. You'll still need a supported AI coding environment to use them.

Now run your web application locally.

For example, an Angular development server commonly runs at:

http://localhost:4200

Open your supported AI agent interface and ask the Planner to create test scenarios for your signup page.

Then use the Generator to create tests from the plan.

To execute the tests, run:

npx playwright test

If something fails, the Healer can help investigate.

A useful detail from the official documentation is that the Planner can use a seed test to understand the application's setup, dependencies, and authentication requirements.

This becomes important when testing applications that require login or special test data.

For the complete setup and agent workflow, see the official Playwright Test Agents documentation.

Does this mean we no longer need QA engineers?

I don't think so.

AI can help reduce repetitive work, but software testing involves much more than clicking buttons and checking messages.

Consider a payment application.

An AI agent might verify that clicking Pay Now displays a success message.

But what if the customer was charged twice?

What if the payment succeeded but the database transaction failed?

What if the request was retried after a network timeout?

These are the kinds of situations where domain knowledge and engineering experience matter.

AI may help generate scenarios, but someone still needs to understand the system, identify risks, validate assumptions, and decide whether the results are meaningful.

For me, the interesting part isn't that AI can write a few lines of Playwright code.

It's that AI agents can help with the broader testing workflow, from planning to maintenance.

That's a more meaningful improvement than simply generating scripts.

A few things I'd keep in mind

If you're planning to introduce AI agents into an existing project, I'd start small.

Choose one feature, perhaps login or signup, and see how the agents behave.

Review the generated scenarios before running them.

Run tests against a development or dedicated test environment, not production.

Make sure you control the test data. Registration tests can easily create dozens of unwanted accounts if you're not careful.

And most importantly, never assume that a green test result automatically means the feature is working correctly.

Final thoughts

Playwright Test Agents are an interesting step forward for browser automation.

The Planner helps organize what needs testing. The Generator turns those scenarios into code. The Healer helps investigate and repair failing tests.

For beginners, they can make test automation more approachable.

For experienced developers and QA engineers, they offer another way to reduce repetitive work and spend more time understanding application behaviour.

But the fundamentals haven't changed.

A good automated test should verify something meaningful, be repeatable, and fail when the application behaves incorrectly.

AI can help us build those tests. It shouldn't replace our understanding of what we're testing.

One small practical tip: If you're testing a signup flow that requires email verification, you don't always need to use your personal email address. For manual testing, you can use any online temporary email generator such as Temp email to create a disposable inbox and check whether registration or verification emails arrive correctly. For repeatable automated tests, a controlled test inbox or email-testing service is usually a better choice.