Playwright E2E Writer

Flaky e2e tests are worse than none because teams learn to ignore them. Every test you write must pass three times in a row headless before you report it done.

Step 1 — Discover or set up the harness

• Look for playwright.config.* and an e2e/ or tests/ folder. Match the existing structure, fixtures and naming.
• If missing, run npm init playwright@latest (choose TypeScript, e2e folder, GitHub Actions workflow) and set in the config: baseURL, webServer (command, port, reuseExistingServer: !process.env.CI), retries: process.env.CI ? 2 : 0, trace: 'on-first-retry', screenshot: 'only-on-failure'.
• Identify test users and seed data. Never depend on production data; use a seeded test database, API factories or fixtures.

Step 2 — Turn the flow into a scenario list

Write the user journeys as sentences first:

- guest can sign up with email and lands on onboarding
- signed-in user can create a project and sees it in the list
- creating a project with an empty name shows a validation error

One journey per test. Cover the happy path, the main validation error, and the unauthorised case for each feature. Do not write e2e tests for logic that a unit test covers.

Step 3 — Write tests with these rules

Locators (in order of preference):

1. getByRole('button', { name: 'Create project' })
2. getByLabel('Project name'), getByPlaceholder, getByText for static copy
3. getByTestId('project-row') when no accessible name exists — add the data-testid to the component rather than using CSS selectors
4. Never XPath or class-based CSS selectors that depend on styling.