Generation is the beginning of test review.

An AI-assisted workflow can turn an app URL and a task into a draft Playwright file. A useful pipeline still has distinct decisions: discover the pages, describe the user task, choose locators, write assertions, run from clean state, and review the diff. Treat the output as source code proposed by a tool, not as a passing test.

Playwright Codegen can record actions and suggest locators. Molar Cartographer explores authorized applications and captures browser tasks; its generated Playwright export and clean replay remain in beta. Review the exported file, its credentials and fixtures, and the application behavior it claims to protect.

TASK

Plain-English browser task

Describe the behavior and the success condition.

intent first
PROPOSAL

Playwright spec draft

The export includes locators, assertions, and a clean starting state.

diff to inspect
REVIEW

Run the reviewed spec

The committed test decides pass or fail without an inference call.

human decision
Review the generated test before CILet an agent propose the task or repair, then keep the executed check repeatable and reviewable.

Prefer locators that describe the control.

Playwright’s locator guidance recommends user-facing locators such as roles, labels, and text, with explicit test IDs when a stable contract is needed. A generated selector like div:nth-child(3) > span depends on layout. A role locator communicates the control and often survives a CSS refactor.

Code example
await page.getByLabel('Email').fill(testUser.email);
await page.getByLabel('Password').fill(testUser.password);
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();

Review strictness and uniqueness. If two buttons have the same accessible name, decide whether the product needs clearer semantics or the test needs a more precise scope. Do not accept a locator that passes only because it happens to match the first element today.

Ask what the test proves after every important action.

A click is not a business result. After signup, assert the verified account or workspace. After checkout, assert the order and entitlement. After an invitation, assert both the recipient and the granted role. A model can suggest an assertion, but the product owner or engineer must decide whether it demonstrates the behavior worth protecting.

Watch for weak generated checks: page loaded, URL changed, button disappeared, or text contains a generic “success.” Pair the visible assertion with a downstream record when the workflow crosses a service boundary. A screenshot can support investigation; it cannot replace the assertion.

Run the exported file from clean state.

Before making generated code part of CI, review its setup and run it twice from equivalent starting conditions. Confirm that it creates or selects the intended test identity, resets service data, waits on meaningful state, and leaves no customer or live-provider side effect. Make the test fail deliberately once so you know the assertion catches the intended regression.

Code example
npx playwright test e2e/checkout.spec.ts --trace on
npx playwright show-trace test-results/checkout/trace.zip

Playwright’s Trace Viewer can open the saved trace for action, DOM, network, and console inspection. In CI, prefer a configured failure or retry trace policy instead of recording everything by default when that cost does not fit your workflow.

Keep generated changes reviewable.

Commit the reviewed spec, fixtures, and any test data contract together. When the app changes, compare the proposed locator or assertion with the failure that prompted it. A repair that changes “account has Pro access” into “checkout page loaded” has hidden the regression. Keep the original intent visible in the test name and assertion.

Use version control to review generated diffs, and rerun the test after editing it. Model output can vary between runs, so avoid treating a regenerated file as a harmless formatting update. Check imports, async handling, fixture scope, and command syntax the same way you would for handwritten Playwright code.

Keep payments and credentials in a test environment.

Generated checkout tests should use Stripe test mode or a supported clone, never a live payment credential. The Stripe checkout guide explains the payment, callback, and account assertions that belong in one task. Molar’s beta export is a starting point for review; it does not establish that the generated file is ready for your repository or release gate.

Explore Cartographer, watch a recorded browser task, or talk to us with the setup and limits of your app in view.

When a locator fails, repair the cause you can explain.

Start with the trace and the accessible structure at the failed step. If the button’s accessible name changed because the product copy changed, update the locator and review the product behavior. If the generated selector depended on a wrapper or position, replace it with a role, label, or explicit test ID that expresses the intended contract.

Code example
const checkout = page.getByRole('region', { name: 'Checkout' });
await checkout.getByRole('button', { name: 'Pay now' }).click();
await expect(page.getByText('Payment confirmed')).toBeVisible();

Run the repaired test from the same clean state and inspect the diff. A passing rerun is evidence that this scenario works; it does not prove every route, browser, payment method, or generated test is correct.