test-driven-development

Test-driven development requires writing a failing test first to prove desired behavior before writing any production logic. This prevents shipping unverified code by establishing correctness through the red-green-refactor cycle, verifying each behavior twice.

To use the red-green-refactor cycle, write one failing test per behavior to demonstrate the missing functionality. Then write minimal code to make it pass, re-verify the green state, and refactor only after confirming the tests remain green.

Yes, test-first development applies to bug fixes and refactoring by making behavior changes explicit and reducing regressions. You start by writing a failing test that captures the bug or desired behavior before modifying the production code.

The best way to structure tests for behavior changes is to require one clear test per behavior. You must confirm a failing state before coding, write minimal code to pass, and mandate re-verification after reaching green to ensure correctness.

You need to confirm a failing test state before writing implementation code to ensure the test actually validates the missing behavior. This prevents false positives and proves that your production code is what drives the test to pass.

You should not use the test-driven development approach when you cannot establish one clear test per behavior or when exploring highly experimental prototypes where desired behavior remains undefined and unverified changes are acceptable.