Testing strategy
Designs test coverage plans and verification gates. Use when writing tests, planning coverage, asking how to test a change, or designing a test plan before implementation. Do not use for red-green-refactor implementation loops (use tdd) or stop-the-line failure triage (use debug).From its SKILL.md
npx -y skills add IcodeNet/agent-skills --skill testing-strategyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.6 KB, 281 tokens by cl100k_base, as published. Nobody here has run it
Testing Strategy
Pick the smallest layer that catches the risk. Encode gates before coding.
Workflow
- Name the risk — what breaks for users or contracts if this change is wrong?
- Choose layer — unit → component → integration → e2e → mutation/property. Prefer the lowest layer that would have caught the bug. See
references/layer-matrix.md. - Write the plan — for each behavior: test name, command, pass/fail check.
- Regression first for bugs — failing test before fix.
- Feature/bug sign-off — include behavior verification beyond smoke (targeted e2e or exploratory checklist with expected outcomes).
- Strengthen — mutation, property, or contract tests when logic is high-risk or shared.
Constraints
- Prefer the project's package scripts; do not invent ad-hoc runners or silence output.
- Smoke-only green is not enough to claim “fixed” or “delivered” when user-visible behavior changed.
- Prefer behavior assertions over implementation-detail tests.
Verification
- Each planned behavior has a named test + command
- Layer choice justified (not “e2e for everything”)
- Sign-off gates listed for the change type
- Blockers stated if a gate cannot run
What ships with it: 1 file
672 B alongside SKILL.md
references/
- layer-matrix.md672 B