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.

Open in Test Case Prompt Generator

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.

How to use this resource

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

FAQ

What failure cases does this checkout E2E prompt cover beyond the happy path?

Five listed under FAILURE SCENARIOS, each getting at least one test: the user refreshes or navigates away mid-flow, a slow network turns instant steps into waits, the session expires between steps, the user double-submits the final action, and the back button revisits a completed step. It generates the Playwright test file for these; you run the suite and confirm it against your real stack.

Why does the generated Playwright file avoid sleeps and CSS selectors?

To survive UI churn and stay CI-safe. FRAMEWORK GUIDANCE locates by user-facing attributes — getByRole, getByLabel, getByText — not "CSS chains that break on restyle," and says "Never sleep: rely on auto-waiting and web-first assertions." Flaky patterns are treated as defects in the tests. The prompt produces one runnable file; you execute it and own whether it passes.

Can I use this to figure out why my checkout flow is currently broken?

It generates tests, it doesn't diagnose. The instruction is "Generate tests only — do not modify the implementation," and the notFor line sends "Diagnosing why a flow currently fails" to the Debugging Prompt Generator. Use this to pin behavior — asserting both what the user sees and what the system stores — and use debugging when you need a root cause.

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
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.

More resources from Test Case Prompt Generator

Resource

Playwright Test Prompt

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

Engineering

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

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.