test-driven-development

1# Test-Driven Development (TDD)
2 
3## Overview
4 
5Write the test first. Watch it fail. Write minimal code to pass.
6 
7**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
8 
9**A strong default in service of shipping — not a law that outranks it.** TDD earns its keep where a failing test pins down behavior you'd otherwise get wrong: core logic, contracts, tricky edge cases. Match it to stakes — reach for it where test-first genuinely de-risks the change; throwaway prototypes, one-line copy tweaks, and obvious glue don't need the ceremony. Don't dodge it with synonyms; equally, don't let it block you from shipping the working thing.
10 
11## When to Use
12 
13**Use test-first for selected behavior where regression risk warrants it:**
14- New features
15- Bug fixes
16- Refactoring
17- Behavior changes
18 
19**Choose proportionate verification for work such as:**
20- Throwaway prototypes
21- Generated code
22- Configuration files
23 
24Resolve the task's selected project/mission/slice procedure first. A required
25TDD step remains required within that scope; changing it needs the authority
26named by that selection. Outside it, choose verification that can detect the
27failure without adding a human approval ritual. The procedure below describes
28TDD when selected, not a completion gate for every kind of work.
29 
30**Chunk size follows the outcome.** Keep red → green → refactor for the behavior
31being changed and build a coherent chunk. TDD does not require two people,
32…