test-driven-development

Test-driven development for a new feature requires writing a minimal failing test that specifies the intended behavior, making the smallest code change to pass it, and refactoring without adding new behavior.

The red-green-refactor workflow in unit testing is a discipline where you write a failing test for the right reason, implement the smallest production code change to make it pass, then refactor safely.

If your test passes immediately, it indicates the test isn't proving anything. Correct failure verification is required to ensure the test actually captures the expected behavior before implementation.

In test-first development, you should use real code and avoid mocks unless unavoidable. This ensures the failing test accurately verifies the intended behavior of the actual system.

Use a failing test first methodology for bug fixes to prevent regressions. It forces you to specify the expected behavior with a failing test before writing the smallest production code change to fix the issue.

When using test-driven development for refactoring, the limitation is that you must not add new behavior. The process strictly enforces minimal code changes, requiring a failing test first to prove any behavior change.