e2e_skill

Overview

This skill runs end-to-end (e2e) tests, diagnoses failures, and applies targeted fixes for flakes, outdated tests, or implementation bugs. It follows strict rules: never change application logic or API without spec backing, and always gate bug fixes with unit tests. The goal is reliable, spec-correct e2e coverage without masking problems with weak waits or arbitrary delays.

How this skill works

The skill discovers the project e2e configuration and canonical test command, spins up required dev servers, and runs tests with a minimal reporter. When failures occur it parses each failure, reads the test and relevant source code, searches for a corresponding spec, and classifies the failure as flaky, outdated, bug, or unverified. Fixes are applied according to the category rules: stabilize waits and selectors for flakes, update assertions for outdated tests, and fix implementation only when a spec exists and unit tests are present.

When to use it

• Running the e2e suite to validate user flows before a release.
• Debugging intermittent or consistently failing e2e tests on CI or locally.
• Fixing flaky tests that cause CI instability without changing product behavior.
• Resolving test failures that may indicate a spec-backed implementation bug.
• When updating tests after a UI or API change to keep coverage accurate.

Best practices

• Always classify failures using the Failure Taxonomy: flaky, outdated, bug, or unverified.
• Fix flakiness by improving waits and selectors (use getByRole/getByLabel/getByTestId), not by adding timeouts or weakening assertions.
• Never change application logic or API contracts without quoting a spec and adding unit tests first.
• For bug fixes, write or run unit tests before modifying source; unit tests must pass locally.
• Run the suite with a minimal reporter and focus fixes in order: flaky → outdated → bug, then re-run and report.

Example use cases

• Replace a fragile waitForTimeout and CSS selector with auto-waiting locators and getByRole to fix an intermittent login test.
• Update assertions and selectors in a profile test after a header redesign when the app behavior is correct.
• Identify a failing transfer validation as a bug by locating SPEC.md, quote the spec, add unit tests for edge cases, and fix the validation logic.
• Report an unverified failure when no spec exists and ask product/QA whether the test or implementation should change.
• Run targeted e2e runs (grep) to iterate quickly on a single failing flow instead of the whole suite.