testing-strategylisted

# Testing Strategy ## Purpose Tests are not free: they are code that must be maintained, and a bad test is a liability that breaks on every refactor while catching nothing. This skill is about choosing which tests are worth writing, at what level, and what each must prove. The measure of a test is simple: **would it fail if the behaviour it describes broke?** A test that cannot fail is decoration, and coverage that counts it is misleading. ## When to use - Adding tests alongside new work. - After a defect escapes -- the regression test is part of the fix. - When a suite is slow, flaky, or routinely ignored. - When deciding whether a design is testable, which is a design question. - Setting up CI gates. ## When NOT to use - Diagnosing a specific failure. Use `root-cause-debugging`. - Measuring performance. A test asserts correctness; use `performance-profiling-method` for speed, and be wary of timing assertions in functional tests -- they are the main source of flake. - Exploratory or usability testing of a game's feel. That is human playtesting and no automated suite replaces it. ## Required context | Fact | Why it matters | |---|---| | What the code is supposed to do | Tests encode intent; without it they encode current behaviour | | The existing test setup and conventions | A second incompatible framework is a cost | | What is genuinely risky | Effort follows risk, not uniformity | | How the code is built and run in CI | A test that cannot run in CI protects