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.