Test audit

Keep tests that catch a distinct, credible failure of observable behavior or an independent contract. Test count, coverage, and deleted lines are not goals. Follow project test rules. This skill decides test value; tool-specific skills help with syntax and setup.

Gate new and changed tests

Before adding a test or a new case to an existing test, answer these questions from the code and current coverage:

1. What observable behavior, invariant, or independent contract does it protect?
2. What plausible change would break that contract and make this test fail?
3. Which existing test would catch that change? If one already does, what separate risk does the new test cover?
4. What is the closest useful boundary for this contract? A public function may own a pure calculation; an API may own an HTTP contract; a browser flow may own visible behavior.

If an answer is missing, do not add the case; explain why. Prefer one test at the owning boundary. Add a table row for another input to the same contract. A second layer needs a separate transport, storage, or user risk. Small, reversible changes need no new test when existing checks cover their risk.

Test the proof

A new test must pass these checks. For an existing test, a failed check calls for investigation, not automatic deletion.