test-driven-development

Test-driven development prevents regressions by defining expected behavior in a failing test before writing production code. This test-first process reduces uncertainty by ensuring code correctness is proven before implementation begins.

To apply red-green-refactor, write a minimal failing test, verify the failure reason, implement the smallest amount of code to make it pass, re-run the test, then refactor safely without adding new behavior.

Use test-first development for bug fixing when correctness must be proven across typical codebase workflows. Defining expected behavior in a failing test before making production changes reduces uncertainty and prevents regressions.

No, refactoring must only occur after the test suite is green. Controlled refactoring happens post-green without adding new behavior, ensuring the minimal implementation remains correct and verified.

Verifying test failure during the RED phase ensures the test fails for the right reason. This tight verification loop confirms the test accurately captures expected behavior before writing minimal production code to make it pass.

Yes, test-driven development applies to implementing new features, fixing bugs, and refactoring. It enforces a test-first process requiring red-verify failure, minimal green implementation, mandatory re-verification, and safe post-green refactoring.