e2e-testinglisted

# E2E Testing with BDD + Browser Automation Design user journey scenarios in Gherkin, implement them with browser automation, and run them as part of the test suite. ## When to Use This Skill - Project has a web UI or REST API that needs acceptance testing - User wants to define "user journeys" or "acceptance criteria" - Features are integrated and ready for E2E validation - User mentions Cucumber, BDD, Gherkin, Playwright, Cypress, or browser testing ## Core Approach **Gherkin scenarios are the spec. Browser automation is the implementation.** ``` User journeys → .feature files (Gherkin) → step definitions (browser automation) → test runner ``` This is NOT a separate testing phase bolted on at the end. E2E tests are written alongside implementation, just like unit tests. The difference is timing — E2E tests make sense after features are integrated, not while building individual components. ## Choosing Your Toolchain Pick based on what the project already uses: | Stack | Recommended toolchain | Why | |-------|----------------------|-----| | Python backend, minimal frontend | **pytest-bdd + Playwright (Python)** | One test runner, shares fixtures with unit tests | | React/TypeScript frontend | **Playwright Test (JS/TS)** or **Cypress** | Tests share types, selectors, and utilities with app code | | Token-constrained AI agent | **agent-browser** (accessibility-snapshot based) | Uses element refs (`@e1`, `@e2`) instead of full DOM — much cheaper on tokens than screensh