mint-prompt

byKONDURI VARUN

# Prompt: Generate E2E specs with Playwright MCP Use this in Claude Code (or any MCP client) with the Playwright MCP server connected and your app running locally. Copy everything in the code block below, fill in the bracketed placeholders, and send it as-is. ## One-time setup (before using the prompt) ```bash claude mcp add playwright npx @playwright/mcp@latest ``` Make sure your app is running locally (e.g. `npm run dev`) and that this repo's `e2e-suite/` (or wherever you placed it) is open in the working directory, so the agent can see `tests/pages/`, `tests/utils/test-data.ts`, and the existing spec conventions. --- ## The prompt ``` You are extending an existing Playwright E2E suite. Before writing anything, read tests/pages/BasePage.ts, tests/pages/LoginPage.ts, tests/pages/DashboardPage.ts, tests/utils/test-data.ts, and one existing spec in tests/e2e/ so you match this repo's conventions exactly (Page Object Model, @smoke/@regression tags, getByRole/getByLabel/getByTestId selector preference, storageState auth reuse). Do not invent a different structure or style. App under test: [BASE_URL, e.g. http://localhost:3000] Login credentials for exploration: [email] / [password] Flow(s) to cover: [describe the flow in plain language, e.g. "the invoice creation flow: create a draft invoice, add line items, apply a discount, send it, and confirm it moves to the Sent tab"] Do this in order: 1. EXPLORE. Use Playwright MCP to actually navigate the running app and walk through the flow(s) above yourself, step by step, as a real user would. Note the actual routes, the actual accessible names/roles/labels/testids on every interactive element you touch, and the actual UI feedback after each action (toast text, URL changes, new elements appearing). Do not guess or reuse selector names from the existing demo pages if the real app differs -- read what's actually there. 2. IDENTIFY GAPS. Compare what you found against tests/pages/*.ts. If a page object for a screen you visited doesn't exist yet, or is missing methods for elements you interacted with, tell me before writing specs, then create or extend that page object following the same class shape and naming conventions as the existing ones. 3. FLAG MISSING TEST HOOKS. If you find interactive elements with no accessible name, no label, and no data-testid -- meaning there is no reasonably stable way to select them -- list those elements and the file/line where the underlying component is defined, so I can add a data-testid. Do not write a selector based on CSS classes or text content that looks likely to change; flag it instead and move on. 4. WRITE THE SPEC(S). Add one new file under tests/e2e/ (or extend an existing one if the flow clearly belongs there) covering: - The happy path, tagged @smoke - At least one validation/error case (e.g. required field, invalid input), tagged @regression - Any state-dependent branch you observed during exploration (e.g. an item that behaves differently once a limit is reached), tagged @regression Use uniqueTaskTitle-style helpers from test-data.ts (or add an equivalent generator) for anything that creates data, so parallel runs and repeat CI runs never collide on the same record. Wait on real signals you observed while exploring (a toast appearing, a network response settling, a specific element becoming visible) -- never a fixed page.waitForTimeout(). 5. RUN IT. Execute the new spec(s) with `npx playwright test <path> --project=chromium`. If anything fails, use Playwright MCP to re-inspect the live page at the point of failure, determine whether the spec or the selector is wrong, fix it, and re-run until it passes. Do not hand me a spec you haven't actually run. 6. REPORT BACK. Summarize: which files you created/changed, which page objects you extended, any data-testid gaps you're flagging for me to add, and the final passing test output. ``` --- ## Notes on using this well - **Run it flow by flow, not "test my whole app" in one shot.** A focused flow description gets you an agent that explores carefully and writes specs that match what's actually there. A vague, broad ask gets you specs that guess at selectors and fail on the first real run. - **The exploration step is the point.** Skipping straight to "write a spec for X" without letting the agent drive the real app first is what produces brittle, hallucinated selectors. Always let it look before it writes. - **Feed back the data-testid gaps.** Step 3 is designed to surface the actual product-code changes needed for stable tests. Treat that list as a small follow-up PR, not something to work around with fragile selectors. - **Reuse this prompt as your suite grows.** Swap the "Flow(s) to cover" line for each new feature and rerun -- the first three steps (read conventions, explore, identify gaps) are what keep the suite consistent as different people/agents add to it over time.