TDD Methodology

The red-green-refactor cycle is a TDD pattern where you write a failing test first (red), implement minimal code to pass it (green), then clean up without changing behavior (refactor). This enforces test coverage before any production code exists, reducing bugs and improving design through iterative increments.

Enforce TDD by making failing tests a prerequisite: write tests first, watch them fail, implement only enough code to pass, then refactor safely. This discipline prevents untested code, ensures specifications are clear upfront, and creates a natural rhythm of small, verifiable increments.

Yes. TDD supports safe refactoring by requiring passing tests before and after changes. Tests act as a safety net—refactor while green (all tests passing), verify tests still pass, and repeat. This prevents accidental behavior changes and makes refactoring low-risk.

Use TDD when you need high confidence in correctness, clear specifications, or maintainable designs. Writing tests first surfaces design gaps early, prevents over-engineering, and ensures every line serves a tested requirement. It's especially valuable for complex features, shared libraries, and safety-critical code.

A TDD cycle completes when: the failing test passes (green), code is minimal and focused, and refactoring improves clarity without breaking tests. Move to the next cycle by writing a new failing test. Completion marks readiness to commit and move forward.