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
- 参考文档skill.yaml256 B
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
e2eas unavailable, in which case this skill records a gap and stops. - The flow is described as user-visible steps and expected outcomes.
Procedure
- Read the project-local verification guide when present: read its
SKILL.mdand 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. - 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.
- 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.
- Script the flow as a user would: through the public interface only, never by reaching into internal state to set up or check results.
- Select stable handles: dedicated test attributes or public identifiers the suite already uses, not layout positions or visible text that changes with copy edits.
- Wait on conditions, never on fixed delays. A sleep hides timing problems until the day the environment is slower.
- Isolate data: each test creates and removes what it needs, so the suite can run in parallel and repeatedly.
- 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
sample-skill
Does a sample task. Use when a sample is needed.
unexplained-contract
Does a sample task. Use when a sample is needed.
shell-block
Does a sample task. Use when a sample is needed.
project-identifier
Does a sample task. Use when a sample is needed.
oversized
Does a sample task. Use when a sample is needed.
no-activation
Does a sample task.