Claude/ChatGPT Prompt to Build a Reliable End-to-End Test Suite

What this prompt does

This prompt casts the model as a senior test engineer who owns CI reliability and asks it to design an end-to-end suite that does not flake, returning working config and real tests rather than pseudocode. Four placeholders shape it: [tool] (Playwright or Cypress), [app] (the app under test), [ci] (the CI provider for sharding config), and [critical_flows] (the user journeys the example tests cover).

The structure works because a flaky E2E suite is worse than none — people stop trusting red builds and re-run until green. By requiring auth fixtures via storageState so tests skip the login UI, isolated data seeding and teardown, parallelism and sharding for [ci], a retry policy behind a quarantine tag rather than a blanket retry, visual-regression baselines, and reporting with traces and flaky-rate trends, the prompt builds reliability in from the start. The quarantine tag is what makes you fix flake instead of burying it. Scoping the example tests to [critical_flows] keeps the suite focused on journeys that actually matter, and naming [ci] ensures the sharding and reporting config targets your real pipeline rather than a generic one.

When to use it

• You are standing up an E2E suite for [app] and want it reliable from day one.
• Your existing suite flakes and the team has stopped trusting red builds.
• You need auth fixtures via storageState so tests skip the login UI per role.
• You want sharding and parallelism configured for [ci] with deterministic ordering.
• You need a retry policy that tolerates real flake without hiding genuine failures.
• You want visual-regression checks and reporting with traces and flaky-rate trends.

Example output

Expect a full [tool] config plus three example tests covering [critical_flows] for [app]. The config includes auth fixtures using storageState (one helper per role), test-data seeding and teardown for isolated runs, parallelism and sharding for [ci] with deterministic ordering, a retry policy gated behind a quarantine tag, visual-regression baselines on key screens, and reporting that surfaces failures, traces, and a flaky-rate trend. The three tests demonstrate the patterns against your real flows.

Pro tips

• Put the retry policy behind a quarantine tag, not a blanket retry, so you fix flake instead of burying it under reruns.
• Use storageState auth fixtures so tests skip the login UI; logging in through the UI every test is a major flake source.
• Keep [critical_flows] to the journeys that actually matter (e.g. signup, add-to-cart, checkout) rather than trying to cover everything.
• Make seeding and teardown isolate each run; shared mutable data is the classic cause of order-dependent flake.
• Match the sharding config to [ci] and keep ordering deterministic so failures are reproducible across shards.
• Commit visual-regression baselines deliberately and review diffs before updating them, so a real layout break is not silently accepted as the new baseline.
• Watch the flaky-rate trend in reporting; a rising rate is an early signal to quarantine and fix before the whole suite loses trust.