cm-tdd

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-execution or cm-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.md for normal execution.
• Load test-quality.md when designing or reviewing tests.
• Load rationalizations.md only when the user or agent is trying to bypass TDD discipline.
• Load bugfix-example.md only for coaching or example use.
• Load stuck-debugging.md only 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.