konradcinkusz Building an E2E acceptance suite worth trusting
Read references/E2E-ACCEPTANCE-TESTING.md before applying any of this.
That file is the standard; everything below it is a summary to help you decide
whether this skill applies and to check your work afterwards.
Reference-architecture principles: P13.
What this standard covers
- The audit that motivated this guide
- The one rule: a test may not pass without checking anything
- Locators: pick a convention before the first component ships
- Waiting: web-first assertions only, and verify your framework agrees
- Independence, cleanup, and parallelization have to agree with each other
- CI wiring is part of "done," not a follow-up
- One canonical suite per live frontend
- Auditing a suite you inherited, especially an AI-bulk-generated one
Checklist
A suite claiming to be a real regression net answers yes to all of these:
- Every passing
[Fact]/[Test]executes at least one unconditional assertion against real application state — no guard-then-bail before the only assertion, no swallowed assertion failures - Anything not yet implemented is
[Fact(Skip="reason")](or the framework equivalent), never a silently-passing placeholder - Locators prefer role/accessible-name first,
data-testidas the deliberate fallback where no accessible name exists; the convention was agreed before the first component shipped, not retrofitted - No fixed sleeps as the primary wait strategy; any custom assertion-wait helper has been read (not just trusted by its signature) to confirm it actually retries
- Tests that don't specifically exercise login/registration start from a saved
storageStaterather than driving the login form every time - Mutation testing (Stryker.NET or equivalent) has been run at least once after any assertion-discipline pass, to confirm the real assertions actually catch broken code
- Any locator built from a list/delimited string has been checked against the framework's actual matching semantics, not the semantics that seemed intuitive
- Test data generation (independence) and test data teardown (cleanup) are both handled, deliberately, for the environment the suite actually runs against
- Declared parallelization safeguards have real member tests; anything relying on shared/seeded (not generated) state is verified to be serialized
- The suite runs automatically — PR smoke subset at minimum — against an environment
this estate's pipeline already provisions, not only by a developer's local
dotnet test - Exactly one canonical suite targets each live frontend; a retired/renamed frontend's old suite is archived or ported in the same change, not left to drift
- If inherited or bulk-generated, its own counts and claims have been spot-checked against the actual code before being trusted
Generated from docs/guides/E2E-ACCEPTANCE-TESTING.md by scripts/build-marketplace.mjs. Do not edit this file: change the source document, or its entry in catalog/marketplace.catalog.json, and re-run the generator.