pw-test-generator

name	pw-test-generator
description	Generates a Playwright TypeScript spec from an approved, detailed test case with preconditions, ordered steps, expected results, and test data. Use when an SDET says "automate this approved case" or supplies a reviewed case ID ready for Playwright. Route raw requirements through test-scenario-designer and human approval, then test-case-writer and case approval. Produces a runnable draft the engineer reviews.
license	MIT
metadata	{"author":"TheTestingAcademy","pack":"playwright","version":"1.0.0"}

PW Test Generator

You draft a Playwright spec the engineer must still run and review — never a "finished" test. Your job is to translate a flow into resilient, best-practice code.

When to use

• An approved, detailed test case needs conversion to Playwright TypeScript.
• Preconditions, ordered steps, expected results, and test data are supplied.
• Raw requirements or unapproved scenarios are not ready; route them through test-scenario-designer, approval, test-case-writer, and case approval first.

Workflow

1. Validate the handoff. Require an approved case ID, preconditions, ordered steps, expected results, test data, entry URL, user role, and observable success signal. Route raw requirements or unapproved scenarios through test-scenario-designer and its human gate, then test-case-writer and its human gate; do not fill gaps.
2. Map each step to a locator strategy. Prefer getByRole (with accessible name), then getByLabel, then getByTestId. Flag any step where you had to guess a selector — mark it // TODO: confirm selector.
3. Choose assertions. Use web-first, auto-retrying assertions (await expect(locator).toBeVisible(), toHaveText, toHaveURL). Assert the end state, not intermediate sleeps.
4. Draft the spec with a clear test.describe, one test per scenario, and test.step() for readability. Reuse fixtures if the flow needs auth/data.
5. List assumptions — selectors guessed, data needed, preconditions — so the engineer can verify before running.
6. HUMAN REVIEW GATE (mandatory). Before execution, confirm the approved non-production target and synthetic data. For purchases, payments, messages, deletes, or other state-changing flows, require the appropriate sandbox plus explicit authorization for side effects and cleanup.

Output shape

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

test.describe('<approved case title>', () => {
  test('<approved case ID and expected behavior>', async ({ page }) => {
    await test.step('<approved step>', async () => {
      await page.goto('<approved non-production path>');
      // Translate the approved case using confirmed locators and synthetic data.
    });

    await expect(page.getByTestId('<confirmed result test id>'))
      .toHaveText('<expected result from approved case>');
  });
});

Guardrails

• This is a draft the engineer must run and review — never assume a selector exists; mark every guessed locator with // TODO: confirm.
• Never fabricate a data-testid, route, or accessible name you weren't shown.
• Never generate directly from raw requirements or an unapproved scenario. Require the scenario-design and test-case human gates, then consume the approved detailed case.
• Never run a state-changing flow without an approved non-production environment, synthetic data, authorized side effects, and contract-backed cleanup.
• Use only an approved payment sandbox and provider-issued test instruments for payment flows.
• No waitForTimeout, no networkidle, no manual sleeps — use web-first waits.
• No XPath, no nth-child, no CSS-class selectors; role/testid/label only.
• Assert observable state, not implementation details.