test-driven-developmentlisted

# Test-driven development **Trigger.** You are about to add or change behaviour — a feature, an edge case, a bug fix, a refactor with a semantic change. Also load it when you notice you have written code and are about to write its test. > **Reference material** (what a legitimate red looks like per runner, test > granularity and doubles, applying the loop to legacy code without tests): > see `reference.md` in this directory. ## The rule > **A test you have not seen fail proves nothing.** This is the whole discipline in one line. A test written after the code passes on its first run, which means you have observed exactly one fact: the test executes. You have not observed that it tests *your* behaviour, that it would catch a regression, or that its assertions are reachable. Tests that were never red are the most common form of coverage theatre: the number goes up, the safety does not. ## The loop ### RED — write a failing test 1. Name the behaviour in one sentence: *given X, the system does Y*. 2. Write the smallest test that asserts it. 3. **Run it. Watch it fail.** 4. **Read the failure message.** This is the step that carries the value. A legitimate red fails *for the reason you intended*: | Failure | Verdict | | --- | --- | | `AssertionError: expected 3, got 0` | Legitimate — the behaviour is absent | | `AttributeError: no attribute 'parse'` | Legitimate for new API surface | | `ImportError` / `fixture not found` | **Not a red** — the harness is broken | | `Synta