test-driven-developmentlisted

# Test-Driven Development ## Overview TDD is a design technique, not a testing technique. Writing the test first forces you to design the interface before the implementation: the test is your code's first client, and if the test is awkward to write, the API is awkward to use — you learn that before committing to an implementation, when the cost of change is still zero. Default to test-first: you need a reason NOT to write the test first, not a reason to. This skill teaches the full Red-Green-Refactor cycle, the cases where TDD genuinely doesn't apply (see Decision Points), and the hardest case — applying it to brownfield code where nothing is tested yet. ## The Cycle The TDD cycle has three phases. They repeat for every behavior you add. The discipline is in the repetition — each cycle is small (5-15 minutes), and you never skip a phase. The order matters: Red forces you to think about what you want, Green forces you to make it work, Refactor forces you to make it clean. Skipping any phase breaks the feedback loop. ### Red: Write a Failing Test **What to do.** Write a test that describes the next behavior you want. Run it. Watch it fail. Confirm it fails for the right reason. **How to do it well.** The test describes WHAT the code should do, not HOW it does it. Test behavior through the public interface. Name the test after the behavior: `test_order_total_includes_tax()`, not `test_calculate()`. The name should read like a specification — if someone reads only your te