Engineering

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Overview

Playwright tests fail two ways: flaky (sleeps and fragile selectors) or unmaintainable (CSS chains that break on every restyle). This setup generates the Playwright contract for an E2E journey with the framework's own discipline: locate by user-facing attributes (getByRole, getByLabel) so restyles don't break tests, never sleep — auto-waiting and web-first assertions do the waiting, every test starts from a clean context, and page objects only where flows are actually reused.

Workflow

Generate with the journey preset
E2E strategy + Playwright mode: journey philosophy plus framework discipline in one contract.
Audit the locators
Every getByRole the model produces is a test that survives a restyle; every CSS chain is a future failure.
Reject any sleep
The contract bans fixed waits — if generated code sleeps, regenerate with the contract quoted back.

Why This Works

User-facing locators align tests with what users do, not how the DOM is shaped today
Auto-wait discipline removes the #1 source of E2E flake at the contract level
Clean-context rules keep tests independent — parallelizable and debuggable

Best for

Teams adopting Playwright from Selenium or Cypress
E2E suites where flake is the main maintenance cost
Modern web apps with accessible, role-labeled UI

Not for

Selenium projects — switch the framework mode; the discipline differs (explicit waits, stale elements)
API testing — Playwright can do it, but the API strategy with generic mode contracts it better

Use cases

Generating Playwright journeys that survive UI restyles
Converting sleep-ridden specs into auto-waiting ones
Onboarding a team to Playwright's locator philosophy

Customize This Resource

Opens this setup in Test Case Prompt Generator. Generate to get the full test contract — then adjust the strategy, framework, coverage, and depth.

Open in Test Case Prompt Generator

Prompt Template

TESTING OBJECTIVE
Generate Playwright tests for the onboarding journey.
Strategy: end-to-end tests — realistic user journeys through the real system.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the flow under test here]

TEST STRATEGY
- Test user journeys, not functions: each test walks a realistic workflow from entry to outcome.
- Run against the real stack with minimal mocking — only truly external services (payments, email) get faked.
- Assert what the user sees and what the system stores — both ends of the journey.
- Selectors and waits must survive UI churn: stable locators, no fixed sleeps.

COVERAGE AREAS
Happy Path:
- The primary success path with realistic, typical inputs
- The most common variations users actually exercise
- Expected outputs asserted precisely — values and shape, not just "no exception"

EDGE CASES
- null/None/undefined inputs at every entry point
- Empty strings, collections, and payloads
- Minimum and maximum allowed values
- Just-inside and just-outside boundary values (off-by-one)
- Malformed and wrong-type inputs
- Unicode, emoji, and special characters in text inputs

FAILURE SCENARIOS
Each of these gets at least one test:
- The user navigates away or refreshes mid-flow
- A slow network turns instant steps into waiting steps
- The session expires between steps
- The user double-submits the final action
- The browser back button revisits a completed step

TEST DATA GUIDANCE
- Use realistic, production-shaped data — names, amounts, and dates that could exist.
- Build complex objects with builders or factories, not hand-assembled literals repeated per test.
- Name boundary data for its intent (maxLengthName, expiredToken), not its value.
- Never share mutable fixtures between tests.

FRAMEWORK GUIDANCE
Framework: Playwright.
- Locate by user-facing attributes — getByRole, getByLabel, getByText — not CSS chains that break on restyle.
- Never sleep: rely on auto-waiting and web-first assertions (await expect(locator).toBeVisible()).
- Each test starts from a clean context — no test depends on another test's navigation.
- Use page objects only for flows reused across tests; inline locators are fine for one-offs.

OUTPUT FORMAT
- Return one complete, runnable test file in Playwright.
- Group tests by coverage area, with a comment header per group.
- Each test: arrange-act-assert structure, one behavior per test.
- Cover every selected coverage area systematically — each coverage item above gets at least one test.
- Parametrize repetitive cases instead of copy-pasting tests.
- Name tests so a failure message alone identifies the broken behavior.

ASSUMPTIONS
- After the tests, list every assumption you made about unspecified behavior under an ASSUMPTIONS heading.
- Where the code's intent is ambiguous, test the most likely intent and flag the ambiguity.
- List GAPS: behaviors you could not test with the information given.

NON-GOALS
- Do not rewrite or "improve" the implementation code — test it as it is.
- Do not refactor the architecture to make it more testable; flag testability problems instead.
- Do not invent requirements — test only specified or clearly implied behavior.
- Do not weaken assertions to make tests pass.

Related Resources

Explore more resources that work well with this one.