test-driven-development

The Red-Green-Refactor cycle in test-driven development is an iterative process where you write a failing test, write the minimum implementation code to pass that test, and then refactor the code to improve quality while maintaining passing tests.

To fix a bug using test-driven development, you write a new failing test that reproduces the specific bug behavior before modifying any implementation code, ensuring the fix prevents future regressions once the test passes.

Test-driven development works for refactoring existing software by relying on established tests to verify behavior, allowing you to safely restructure internal code without introducing regressions during the refactor phase.

The best way to start new features using TDD is to strictly write a failing test that defines the expected behavior first, then write the implementation code needed to make that test pass before moving to refactoring.

Writing failing tests before implementation code is required to verify the test actually checks the expected behavior, preventing false positives and ensuring your software development process reliably prevents regressions.

Test-driven development is less suited for exploratory software development or throwaway prototypes where behavior is undefined, as the methodology requires knowing specific expected behaviors upfront to write failing tests first.