test-driven-development

Test-driven development prevents bugs by enforcing a strict red-green-refactor cycle where you write a failing test before any production code, then write minimal code to pass the test, and finally refactor while ensuring tests stay green.

The red-green-refactor cycle in TDD is an iterative process: write a failing test describing desired behavior, write the smallest amount of code necessary to make it pass, and then clean up the implementation through refactoring.

To write a failing test first, describe the desired behavior for your new feature or bug fix before writing any production code. This ensures the test fails initially, proving the feature is not yet implemented and preventing regressions.

Fixing bugs without a failing test violates the iron law of test-driven development. All behavior changes and bug fixes must be preceded by a failing test to ensure code reliability and prevent future regressions.

Test-driven development supports refactoring by ensuring existing tests remain green while you clean up code. The strict red-green-refactor cycle guarantees that structural improvements do not introduce regressions or alter behavior.

Test-driven development may not suit exploratory prototyping where behavior is undefined, as the methodology requires a strict test-first approach and mandates adherence to writing a failing test before any production code.