Turn a live website into a Playwright test you can trust

Playwright already ships an excellent local recorder. Run npx playwright codegen https://your-app.example, perform a journey, and it produces actions and locators. The official codegen guide explains the workflow and its preference for role, text, and test-id locators.

That is the fastest route from zero to a first draft. For a single flow, start there. When you need to discover journeys across a live application, generate repeatable specs, execute them, and preserve run evidence, use a Playwright test generator built around the whole loop.

Codegen or an AI generator?

Use Playwright codegen when a developer knows the exact path and wants to record it now. You drive the browser, codegen suggests resilient locators, and you edit the result in your repository. It is direct, local, and already part of Playwright.

Use an AI generator when the input is an outcome rather than a click script: explore a live application, find the steps that reach that outcome, draft the assertions, and keep the execution artifacts together. That is especially useful when the surface spans several routes or the person describing the journey does not know the DOM.

The two approaches are complementary. QualityMax produces Playwright—not a proprietary replacement for it—so the resulting spec still belongs in normal code review and runs through the standard Playwright runner.

1. Choose a user outcome, not a page tour

Write one sentence that a product owner could verify: “A signed-in buyer can add a product and see the correct total at checkout.” It gives the generator a destination and, more importantly, tells the test what must be asserted.

Keep authentication and test data explicit. Generation can inspect what the browser actually exposes, but it cannot infer the business truth behind an ambiguous total or invent credentials safely.

2. Observe the real DOM and interactions

Point QualityMax at the live or preview URL and the intended journey. Its crawler observes rendered elements and interactions before generating the spec. That grounding matters on modern apps where routes, labels, and enabled states only exist after JavaScript runs.

3. Review the generated contract

The output should read like a small product contract. Prefer user-facing locators and assert outcomes that would actually catch a regression. The example below is representative code, not a transcript from a customer project.

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

test('buyer sees the checkout total', async ({ page }) => {
  await page.goto('https://shop.example/products/field-notes');
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: /cart/i }).click();

  await expect(page.getByRole('heading', { name: 'Your cart' })).toBeVisible();
  await expect(page.getByTestId('order-total')).toHaveText('€29.00');
});

Do not approve a test merely because it has steps. Check that it would fail if the feature broke. A visible checkout heading plus the expected total is stronger than “the page loaded.” This is the same separation behind QualityMax's independent AI code testing: generation proposes; deterministic assertions decide.

Five questions before you merge the draft

• Does the test name describe a user-visible outcome?
• Do locators prefer roles, labels, text, or intentional test IDs over CSS structure?
• Would at least one assertion fail if the feature delivered the wrong result?
• Are credentials and seed data supplied through approved fixtures rather than embedded in the spec?
• Can another developer run it with the repository's documented Playwright command?

4. Run it with failure evidence

Run the generated spec in your checked-out repository or in an isolated test automation sandbox. The standard Playwright CLI remains the portable contract:

npx playwright test tests/checkout.spec.ts --trace on

Keep the trace, screenshots, video, and console output attached to the run. A red test with a trace is an actionable bug report; a red test with only a stack line becomes detective work. See the official test CLI reference for runner options.

On CI, use the repository checkout so imports, fixtures, and configuration resolve exactly as they do for the rest of the suite. A self-contained cloud sandbox is useful for generated probes and isolated experiments; it is not a magic substitute for source code the test depends on.

5. Treat healing as a reviewed locator change

When the UI changes, self-healing tests can propose a new way to locate the same element. They must not rewrite the expected total or quietly redefine success. In QualityMax, a repair remains pending for authenticated human review before apply.

Where generation stops

• Business truth: you supply the expected outcome and trustworthy test data.
• Authentication: use an approved test account or repository fixture; never paste production secrets into a prompt.
• Repository fit: review imports, fixtures, projects, and CI settings in your checkout.
• Judgement: keep assertions deterministic and review generated code like any other change.