principle-tddlisted

# Test-Driven Development ## The loop 1. **Red** — one failing test describing the next slice of behavior. Run it; confirm it fails for the right reason. 2. **Green** — simplest production code that passes. Hard-coding is allowed — it will be driven out by the next test. 3. **Refactor** — with all tests green, improve the code and the tests. Never refactor on red. Each cycle is minutes, not hours. ## Rule of three Duplication triggers refactor on the third occurrence. Two is coincidence; three is pattern. ## F.I.R.S.T. - **Fast** — milliseconds. - **Isolated** — independent of order and other tests. - **Repeatable** — deterministic anywhere. - **Self-validating** — automatic pass/fail. - **Timely** — written just before the production code. ## What counts as "refactor" *Structural improvement with all tests green — no new behavior.* - **Rename, extract, move** — anything that clarifies intent or repositions code to the layer that owns it. - **Never add behavior during refactor** — if a test turns red mid-refactor, revert the last step; the cycle was too large. - **Tests are part of refactor too** — clean up names, builders, and assertions when production code changes shape. ## Test doubles — pick the cheapest that works *One double per behavioral boundary, not one double per collaborator.* - **Fake** — working implementation (in-memory DB) — best for fast integration without real infrastructure. - **Stub** — canned response — isolates the path under test. - **Spy** — re