test-driven-development

The test-driven development process follows a Red-Green-Refactor loop: write a failing test first, verify it fails for the expected reason, implement minimal code to pass, re-verify, then refactor only while tests stay green to ensure software quality.

To implement a bug fix using test-first development, write a minimal behavior-focused failing test that reproduces the bug, verify the test fails because the feature is missing, implement the smallest code change to pass the test, verify the pass, then refactor.

Verifying a unit test fails for the expected reason prevents untrustworthy code changes by ensuring the test actually targets the missing feature. This strict test-first guardrail confirms the test is valid before you implement any minimal production code to pass it.

You should not use the test-driven development workflow for refactoring if your tests are not green first. The TDD workflow requires refactoring only after tests pass, ensuring you clean up code without adding new behavior while maintaining regression protection.

If you rationalize writing tests later by claiming manual testing is sufficient or keeping code as reference, you should delete the code and restart the TDD loop. This anti-rationalization discipline enforces writing a failing unit test before any production implementation.