AGENT SKILL

e2e-testing

Write end-to-end tests for important user-visible flows through the system's public interface. Use when a claim spans a complete flow that unit or integration tests cannot prove.

License 许可
MIT
最近更新
2026-11-14
Stars
★ 1
Forks
0

01 前言 Front Matter

name
e2e-testing
description
Write end-to-end tests for important user-visible flows through the system's public interface. Use when a claim spans a complete flow that unit or integration tests cannot prove.

02 资源文件 1

03 SKILL.md 正文

End-to-end testing

When to use

For critical flows only: those whose failure a user would notice first, and claims that depend on many components working together. Use a project-local verification skill when one documents how to reach and exercise the real interface. Everything a lower level can prove belongs there; end-to-end tests are the slowest and least precise.

Required context

The verification profile (how end-to-end tests run and against what environment). Useful: the product context (which flows are critical), the feature map (entry points), and any project-local verify-* skill under .paved/skills/.

Preconditions

  • The project has an end-to-end setup, or the profile records e2e as unavailable, in which case this skill records a gap and stops.
  • The flow is described as user-visible steps and expected outcomes.

Procedure

  1. Read the project-local verification guide when present: read its SKILL.md and feature map, then use only its documented launch, readiness, interaction, evidence and cleanup paths. If a claim is stale, confirm it against the source and report the mismatch.
  2. Discover the existing suite: where it lives, how it starts the system, how it selects elements or calls endpoints, how it creates and removes test data, and how it waits for asynchronous results.
  3. Check lower levels first. If a unit or integration test can prove the claim, write that instead and say why no end-to-end test was added.
  4. Script the flow as a user would: through the public interface only, never by reaching into internal state to set up or check results.
  5. Select stable handles: dedicated test attributes or public identifiers the suite already uses, not layout positions or visible text that changes with copy edits.
  6. Wait on conditions, never on fixed delays. A sleep hides timing problems until the day the environment is slower.
  7. Isolate data: each test creates and removes what it needs, so the suite can run in parallel and repeatedly.
  8. Run the test several times; a test that fails intermittently is fixed or removed, not retried until green.

Tools

None. The command and the target environment come from the verification profile.

Rules

None beyond those that apply by scope.

Verification

Required: e2e.

Evidence

A check result for the end-to-end run, with the environment it ran against.

Completion criteria

  • The flow's claims are asserted through the public interface.
  • The test passes on repeated runs.
  • Claims a lower level could prove were tested there instead.

Failure modes

Failure Signal Response
Flaky test Passes on retry Find the race; wait on a condition
Backdoor setup Test writes internal state directly Use the public interface or the suite's fixtures
Pyramid inverted Many end-to-end tests for local logic Move those claims down a level
Environment unavailable Suite cannot start the system Record a gap; do not fake the environment

References

None.

04 同仓库更多 Skills