---
name: e2e-testing
description: Design, run, or repair end-to-end tests for a concrete user journey when browser or full-system behavior must be verified.
---

# E2e Testing

Test behavior through the user-visible boundary. Prefer the project's existing E2E framework and conventions; do not introduce a second browser stack for one test.

## Define the journey

Write the preconditions, user actions, observable assertions, and cleanup. Cover the shortest critical happy path first, then add only high-value failure or permission cases. Use stable accessibility roles, labels, test IDs, or public API contracts. Avoid selectors tied to incidental DOM structure or styling.

## Execute and diagnose

Confirm the application and dependencies can start in the current environment. Run the narrowest test first. On failure, collect the assertion, screenshot, trace, console output, and relevant network evidence that the framework already supports. Separate product defects, test defects, fixture problems, environment failures, and timing flakiness before editing.

Prefer condition-based waits over sleeps. Keep fixtures isolated and deterministic. Never point destructive test flows at production or a shared environment without explicit authorization and safeguards.

When repairing a flaky test, reproduce the instability with repeated runs before changing it. Remove the underlying race or unstable dependency; do not mask it with large timeouts or unbounded retries. Quarantine only when repository policy allows it, ownership is clear, and the reason is recorded.

## Report

State the journey tested, environment, commands run, pass/fail counts, artifacts, and remaining gaps. If browser tooling, credentials, or services are unavailable, report the exact blocked boundary and complete any useful static preparation without claiming the journey passed.