← LeaderboardThe Skill Leaderboard

e2e-setup

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

Published by AI-Builder-Club ↗AI-Builder-Club/skills

Try your first task

e2e-setup

Start a fresh conversation. Replace the highlighted placeholders.

Use e2e-setup to Set up a small, reliable end-to-end test gate for [critical user journeys] against the already-running [local or isolated test stack], with reusable authenticated sessions where appropriate, layered assertions, stable selectors, and gitignored video and trace evidence; use only sandbox/test credentials and refuse live credentials.

Required inputs

  • [critical user journeys]
  • [local or isolated test stack]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: e2e-setupdescription: >  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

  1. 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).
  2. 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.
  3. Explore the flow live first (don't guess selectors), then crystallize it into a committed spec.
  4. 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.