Test-Driven Development (TDD)
TL;DR
- Use when writing or fixing code
- Cycle: Red → Green → Refactor
- Rule: no production code without a failing test first
- Next:
cm-executionorcm-code-review
When to Use
- new features
- bug fixes
- refactors
- behavior changes
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Choose the Need
Need to execute the normal TDD loop?
└─ YES → Red-Green-Refactor
Need help designing or reviewing test quality?
└─ YES → Test Quality
Need to counter "skip TDD" rationalizations?
└─ YES → Rationalizations
Need a worked bug-fix example?
└─ YES → Bugfix Example
Are you blocked or unsure how to continue?
└─ YES → Stuck / Debugging
| Need | Summary | Load |
|---|---|---|
| Normal execution | core TDD loop and verification | references/red-green-refactor.md |
| Test quality | what good tests look like | references/test-quality.md |
| Reinforcement | anti-rationalization guidance | references/rationalizations.md |
| Example | concrete bug-fix walkthrough | references/bugfix-example.md |
| Recovery | how to proceed when stuck | references/stuck-debugging.md |
Load Rules
- Load
red-green-refactor.mdfor normal execution. - Load
test-quality.mdwhen designing or reviewing tests. - Load
rationalizations.mdonly when the user or agent is trying to bypass TDD discipline. - Load
bugfix-example.mdonly for coaching or example use. - Load
stuck-debugging.mdonly when blocked.
Non-Negotiables
- Watch the test fail before writing production code.
- Keep implementation minimal until green.
- Refactor only after green.
- Re-run verification after each meaningful change.
The Bottom Line
Write the failing test first. Pass it minimally. Refactor only after green.