← ClaudeAtlas

testing-strategylisted

Test design for changed behavior — what to check and at which level. Use when deciding what tests to write, change, or skip; when fixing any bug; when choosing between unit, integration, and end-to-end coverage; when introducing mocks or fakes; and when a test is flaky.
voklab/layline · ★ 0 · Testing & QA · score 72
Install: claude install-skill voklab/layline
# Testing strategy Tests are designed, not accumulated. Each one exists because a named risk needs a named oracle at the cheapest level that would catch it — coverage is a side effect, never the goal. ## Select by risk, not by habit Test effort follows blast radius: what breaks, for whom, how visibly, how reversibly? New branching logic, boundary conditions, money/data/security paths, and integration seams rank high; accessors, framework plumbing, and what the compiler already proves rank near zero. Write the high-rank tests first, and say what was deliberately left untested. The pyramid is a budget, not a dogma: put the test where the risk is, at the cheapest level that would actually catch it. Detail: `references/test-selection.md`. ## Regression first — every bug fix A bug is a missing test that got found the hard way. Before fixing: write the test that reproduces it and observe it fail; then fix; then observe it pass. A regression test never seen failing proves nothing about the bug. Where a test is cheap, new behavior earns the same fail-first sequence — one behavior at a time, never bulk-written. Detail: `references/regression-first.md`. ## Seams over mocks Prefer the real thing where it is cheap: real functions, in-memory stores, temporary files. Mock only at hard boundaries — network, clock, randomness, paid third-party APIs, fault injection. Never mock what you own and can run; a test of mocks tests the mocks. Detail: `references/mocks-and-seams.md`. ## Name