E2E Test Generator

---
name: e2e-test-gen
description: |
  Trigger when the user asks to add end-to-end tests, Playwright tests, Cypress
  tests, or browser-automation coverage. Phrases: "e2e test", "Playwright",
  "Cypress", "browser test", "UI flow test".
allowed-tools:
  - Read
  - Write
  - Grep
  - Bash(npx playwright *)
  - Bash(pnpm test:e2e *)
---

# E2E Test Generator

Generate Playwright tests for the critical user flows of a web app.
Prefer Playwright over Cypress for new projects: faster, more reliable,
better TypeScript story.

## Prerequisites

- Playwright installed: `pnpm add -D @playwright/test`
- App runs locally on a known port
- At least one page or flow worth testing

## Steps

1. **Install and scaffold:**
   ```bash
   pnpm create playwright@latest
   ```

2. **Identify the critical flows.** Ask the user which flows block revenue or
   break loudly. Usual suspects:
   - Sign-up and sign-in
   - Checkout or subscribe
   - Core product action (post, upload, save)
   - Search
   - Settings change and persistence

3. **Write one test file per flow.** `tests/e2e/<flow>.spec.ts`:

   ```ts
   import { test, expect } from "@playwright/test";

   test("user can complete checkout", async ({ page }) => {
     await page.goto("/");
     await page.getByRole("link", { name: "Pricing" }).click();
     await page.getByRole("button", { name: "Subscribe" }).click();
     // ...
     await expect(page.getByText("Thanks for subscribing")).toBeVisible();
   });
   ```

4. **Use role-based selectors**, not CSS selectors. `getByRole`, `getByLabel`,
   `getByText`. They survive refactors and document accessibility.

5. **Avoid sleep(). Use Playwright's auto-waiting.** `await expect(...).toBeVisible()`
   waits up to the timeout. If you find yourself reaching for `page.waitForTimeout(1000)`,
   the test is fighting the framework.

6. **Seed real test data via API calls** in `beforeEach`, not by clicking through the UI
   every time. UI setup makes tests slow and brittle.

## Anti-patterns to avoid

- Testing implementation details (classes, specific DOM structure)
- Relying on ambient data that another test created
- Parallel tests that write to shared state
- Screenshots as assertions (they flake on font rendering differences)

## Output

- `playwright.config.ts` with a base URL pointing to the dev server
- One test file per critical flow
- CI workflow entry that runs e2e tests against a preview deploy