| name | e2e-setup |
| description | Set up an end-to-end test suite in any repo, following practices that make e2e a reliable per-PR gate: real flows over bypass, layered assertions, a reusable auth/session helper, video+trace evidence, and a compounding suite. Use when a repo has no e2e (or weak e2e) and you want system-level tests — "set up e2e", "add end-to-end tests", "scaffold a test gate".
|
| user_invocable | true |
Set up an e2e test suite
E2e tests verify the whole running system through the app (browser/API), not one
module. They are the per-PR gate. Pairs with dev-local-setup (a reproducible
local stack) and verifier-setup (which scaffolds the repo's /verify skill —
the verify→ship loop this gate feeds into).
Where it lives
- Unit/integration tests stay inside each app/package — they own one module.
- System e2e is a dedicated top-level package (e.g.
e2e/) — it spans all
apps, so it belongs to none. Add it to the workspace if a monorepo.
The recipe
- Stand the app up reproducibly — see
dev-local-setup. The e2e suite never
boots the app itself; it runs against the already-running stack. That stack can
be local (dev-local-setup) or an isolated cloud box (crabbox-setup) —
same specs, run against either. For parallel agents use the cloud box (one
laptop can't host concurrent stacks).
- Pick the framework that fits (Playwright for browser; your HTTP client for API).
Turn on video + trace — the recording is the proof, and it's gitignored output.
- Explore the flow live first (don't guess selectors), then crystallize it into
a committed spec.
- Keep the gate small: a handful of critical journeys, deterministic. Each new
feature PR adds its spec — the suite compounds.
Practices that make e2e trustworthy
- Real flow, not bypass. Drive the genuine path. For email codes / OTP, read the
real code from a local mail server (Mailpit / Inbucket / MailHog) — never hardcode
a fixed test code. That's what makes it a test, not a rehearsal.
- Verify auth ITSELF once; bypass it everywhere else. A dedicated signup/login
spec proves auth works. Every other spec shouldn't re-pay the login tax — build
a session helper that mints an authed state once (real flow → saved storage
state, or a service-role/token mint) and load it.
- Layered assertions: client → server → product. Don't stop at "the UI changed."
Confirm the server agrees (token validates / row/state is right) AND the
user-visible outcome (e.g. plan upgraded and credits granted).
- Stable selectors. Prefer role/label/text; add a small
data-testid in the
component when there's no good handle — never a brittle CSS path.
- Fresh data per run. Unique emails/ids so reruns don't collide; mind rate
limits (auth email, etc.).
- Commit specs + helpers, never
test-results/ (generated output).
When a test fails: triage before "fixing"
A red e2e is information. Classify first:
- Real bug — the product broke. Fix the code; the test did its job.
- Stale test — the flow intentionally changed (renamed route, new step). Update
the test to match the new contract.
- Flaky / env — stack down, timing, rate limit, stale data. Fix robustness/env.
Never weaken or delete an assertion just to go green. Loosening is only correct
when the intended contract changed — confirmed from the diff, not assumed.
External services (payments, email, 3rd-party)
Use the vendor's test/sandbox mode, never live keys — and guard hard: the
test should refuse to run if it detects a live key/credential. If a webhook
completes the flow, forward it locally (e.g. the vendor's CLI listener) so the e2e
exercises the real fulfilment path, not a faked event.
