Engineering

Playwright Test Prompt

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

Open in Test Case Prompt Generator

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.

How to use this resource

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

FAQ

What flow do I paste into the Playwright test prompt?

Paste the flow under test into the CODE CONTEXT block — the page or component source for one realistic journey, like the onboarding sequence in the TESTING OBJECTIVE. Include the markup or handlers that expose roles and labels so the model can pick getByRole and getByLabel locators. Anything unspecified surfaces under the ASSUMPTIONS and GAPS headings rather than being invented.

How does the getByRole and auto-wait discipline in this prompt work?

The FRAMEWORK GUIDANCE section forces two rules on whatever assistant you run it in. Locators come from user-facing attributes — getByRole, getByLabel, getByText — so a restyle can't break them, and the contract bans fixed sleeps: web-first assertions like await expect(locator).toBeVisible() do the waiting. Each test also starts from a clean context, keeping runs independent and parallelizable.

Does a passing generated Playwright test mean the feature is correct?

Passing tests prove what they assert — the COVERAGE AREAS and FAILURE SCENARIOS the file actually checks — not that the feature is correct. The NON-GOALS bar the model from weakening assertions or touching the implementation, so it tests the code as-is. Take the file the assistant returns, fix what's wrong, and confirm it goes green in CI yourself.

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

Copy it as-is, or use Open in Test Case Prompt Generator to load it pre-filled and customize it with your own context.

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.

More resources from Test Case Prompt Generator

Resource

Unit Test Prompt — Isolation Done Right

Mock the dependencies, test the business logic, one behavior per test — the unit testing contract that bans plumbing tests.

Engineering

Resource

Agent Safety & Refusal Evaluation Prompt

Test the two failure directions — does the agent refuse what it must, and does it stay helpful on the benign requests it shouldn't over-refuse?

AI Agents

Resource

Agent Test Scenario Prompt

Build the test set an agent has to pass — scenarios across the happy path, edges, and adversarial inputs, each paired with the expected behavior to grade against.

AI Agents

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Test Case Prompt Generator

Build test generation prompts — unit, integration, or E2E — with framework modes and edge-case coverage rules.

Coding Workflows

Tip: Save time by exploring related resources and tools that integrate with this resource.