Engineering

E2E Test Prompt — User Journeys, Not Functions

Cart to confirmation as a user would do it — with the failure scenarios real users actually trigger: refreshes, back buttons, double clicks.

Overview

End-to-end tests written like unit tests waste a browser: they poke at elements instead of walking journeys. This setup generates the E2E contract for a checkout flow at production-ready depth: realistic workflows from entry to outcome, minimal mocking (only true externals like payments), assertions at both ends — what the user sees and what the system stores — and the failure scenarios that separate E2E from demos: mid-flow refresh, slow networks, expired sessions, double-submission, and the back button revisiting a completed step.

Workflow

Define the journey, not the pages
Entry to outcome — the contract tests what the user is trying to accomplish.
Keep the failure scenarios
Refresh, back button, session expiry, double submit — the four ways real users break flows daily.
Assert both ends
The confirmation the user sees AND the order the system stored — a journey that only checks one end checks nothing.

Why This Works

Journey framing produces tests that mean something when they fail
User-behavior failure scenarios cover what staging never sees and production always does
Production-ready depth bans the sleeps and ordering that make E2E suites flaky

Best for

Flows where the journey IS the product — checkout, onboarding
Teams whose E2E suite only tests the sunny day
Production-bound flows that meet real browsers and real impatience

Not for

Logic that a unit test reaches in milliseconds — E2E is the expensive tier, spend it on journeys
Diagnosing why a flow currently fails — that's the Debugging Prompt Generator

Use cases

Testing checkout, signup, and onboarding flows end to end
Covering the double-submit that creates duplicate orders
Verifying the journey survives a mid-flow refresh

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
Test the checkout flow end to end, from cart to confirmation.
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"
Error Handling:
- Every declared error path actually triggers in a test
- Errors carry the right type, message, and code
- Failures leave state clean — no partial writes survive
- Errors propagate or are swallowed exactly as specified

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.
- Write for CI: deterministic, parallel-safe, no shared mutable state, no real network or clock unless the strategy demands it.
- Assert behavior, not implementation details — tests must survive refactors that preserve behavior.
- Include the regression net: pin current behavior wherever a future change could silently alter it.
- Treat flaky patterns — sleeps, ordering dependence, time-of-day logic — as defects in the tests themselves.
- Use production-shaped test data, not "foo"/"bar" placeholders.

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.