test-driven-developmentlisted

# Test-Driven Development (TDD) ## Overview Write the test first. Watch it fail. Write minimal code to pass. **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing. **Violating the letter of the rules is violating the spirit of the rules.** ## When to Use **Always:** - New features - Bug fixes - Refactoring - Behavior changes **Exceptions (ask your human partner):** - Throwaway prototypes - Generated code - Configuration files Thinking "skip TDD just this once"? Stop. That's rationalization. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` ### When you've already written the code TDD buys two separable things: **design pressure** on the interface, and **a test proven capable of failing**. Once production code exists, the first is already spent — the interface exists, for better or worse. The second is recoverable without deleting anything: 1. **Write the tests for the hard part first** — the edge cases that took the longest, not the easy paths. 2. **Prove each one can fail.** Deliberately break the logic under test — flip the boundary comparison, off-by-one the arithmetic, drop the fractional carry — and confirm each mutation turns something red *for the right reason*. Revert, confirm green. A mutation that kills no test means that test is decoration; rewrite it before moving on. This is what substitutes for the red you skipped, and it is the step that's easy to skip twice. 3. **Disc