mutantslisted

# Mutants: measure what the tests actually catch Line coverage answers "was this line executed?" — a question no one cares about. A test that calls a function and asserts nothing gives 100% coverage and catches nothing. Mutation testing answers the question that matters: **if this code were wrong, would a test fail?** It introduces a small, plausible defect — `<` becomes `<=`, `return x` becomes `return None` — and reruns the suite. ``` mutant killed -> a test failed -> the suite catches this class of bug mutant SURVIVED -> tests passed -> nothing asserts on this behaviour ``` A survivor is not a hypothetical. It is a concrete edit to production code that the entire suite waves through. ## The reason nobody does this Mutation testing was described in the 1970s and has been the academically accepted measure of suite quality ever since. It stays unused because of two costs: 1. **Whole-repo runs take hours.** So they get run once, in an audit, and never again. 2. **Triaging survivors is tedious.** Many survivors are *equivalent mutants* — the code changed but the behaviour did not, so no test could ever kill them. Separating those from real gaps is slow, unglamorous judgement work. Both are addressable. Fix the first by scoping to the diff. The second is the work this skill exists to do. ## Step 1: scope to the diff, not the repo Mutate only what changed. This turns hours into minutes and makes the technique usable during code review, which is the only