test-driven-development

Test-driven-development begins by writing a minimal failing unit test that defines the desired behavior, verifying it fails for the correct reason, and then implementing only enough production code to make it pass.

The red-green-refactor workflow is a test-first cycle where you verify a failing test, write the smallest code implementation to pass it, and then safely refactor the codebase without altering the confirmed behavior.

To fix a bug using a test-first workflow, you reproduce the expected behavior as a failing test first, implement the smallest possible fix to turn the test green, and ensure the entire unit testing suite remains regression-free.

Common mocking anti-patterns include testing the mock behavior itself rather than the production code, adding test-only methods to production classes, and mocking components without understanding their required side effects.

Yes, test-driven-development supports refactoring by keeping behavior unchanged. You verify existing tests pass, refactor the production code safely, and rely on the test suite for regression prevention throughout the edit loop.

A unit test might fail for the wrong reason if it lacks strict red-green verification or contains mock-focused anti-patterns. You must verify the failing test correctly targets the missing production code before implementing the minimal fix.