test-driven-development

Test-driven development prevents regressions by enforcing a RED-GREEN-REFACTOR workflow where you write a failing pytest test first, implement minimal code to pass it, then refactor safely without adding untested behavior. This cycle ensures reliable correctness and repeatable validation for new features and bug fixes.

The RED-GREEN-REFACTOR cycle is a test-first workflow where you write a failing test (RED), implement the smallest code change to make it pass (GREEN), and then refactor the implementation without introducing new behavior. It forces explicit verification runs to confirm both failing and passing states before and after code changes.

To apply strict TDD for systematic debugging, you write a new failing test that reproduces the specific bug issue first. Once you verify the test fails, you implement the minimal fix to make it pass, verify success, and run the full test suite to ensure no other regressions were introduced during the fix.

Yes, test-driven development requires a mandatory verification loop where you run the specific test to confirm failure and success, followed by running the full test suite to ensure no regressions. This explicit verification step is required after every minimal code implementation and before any refactoring.

You should avoid test-first development when refactoring if it involves adding new behavior, as strict TDD dictates refactoring only happens after GREEN without introducing untested behavior. If your refactor introduces new functionality, you must start a new RED phase with a failing test for that specific behavior first.

The best way to write behavior-focused tests in TDD is to define expected real behavior in a minimal failing test, avoiding fragile implementation details and edge case rationalizations like testing after implementation. You must write the test first and verify it fails before writing any code to pass it.