end-to-end-testing
End-to-End Testing
This skill equips you to author, run, review, and maintain end-to-end (E2E) tests: automated checks that exercise the whole system the way a real user or client does, against a running build rather than mocked-out units. Reach for it to write a new suite, add a test to an existing one, diagnose a flaky or failing run, or judge someone else's e2e change.
The conventions here are framework-agnostic. E2E suites take three broad shapes, and the same principles govern all of them:
- Browser-driven UI (e.g. Playwright, Cypress, WebdriverIO) — drive a real browser against the running web app.
- Device-driven mobile UI (e.g. Maestro, Detox) — drive a real app build on a simulator, emulator, or device.
- Protocol / HTTP-level (e.g. a Vitest suite driving a real REST, GraphQL, or MCP client) — boot the real server and exercise its endpoints with the real client, no browser.
Code examples use one concrete runner (usually Playwright) as the shape. Translate the API to the project's runner — the prose rules are what carry across stacks.
This skill owns the E2E level: whole-system checks against a real build. A check that mocks its dependencies to isolate one unit belongs at the unit level instead — if the project ships a unit-testing skill, defer to it for those conventions.
The level is not the runner. Where an e2e suite runs on a runner the project ships a capability for, that capability owns the runner's own surface — its config file, projects, pools, reporters, and browser-mode wiring — while the journeys, the locator fallback hierarchy, server lifecycle, and scenario coverage stay here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.