test-driven-developmentlisted

# Test-driven development Write the test. Watch it fail. Write the least code that makes it pass. **The load-bearing step is watching it fail.** A test you never saw fail has not been shown to test anything. It may assert nothing, never execute, mirror the implementation back at itself, or cover behavior that already worked — and a green suite hides all four. The red run is the only evidence that the test can catch the bug you are about to fix. That step is checked here, not merely asked for — see [Enforcement](#enforcement). ## The loop ``` Red write one failing test ↓ Verify red run it; confirm it fails, and fails for the reason you expect ↓ Green write the least code that passes it ↓ Verify green run it; confirm it passes and nothing else broke ↓ Refactor clean up, staying green ↓ repeat ``` ## Red — write one failing test One behavior per test. A name containing "and" is two tests. Name the behavior, not the function: `retries a failed call three times`, not `test retry`. Write it against real code. Reach for a mock only when the real dependency is slow or external — and read [writing-good-tests.md](./writing-good-tests.md) before adding one. ## Verify red — the step that gets skipped Run it. Then confirm three things: 1. **It failed rather than errored.** An import error or a typo is not a red phase. Fix it and re-run until the failure is the assertion. 2. **The failure message is the one you predicted.** If you cannot say