test-driven-development

Test-driven development reduces regressions by forcing you to write a failing test that defines expected behavior before implementing production code. This proves the test is valid and ensures your new code works as intended.

The Red-Green-Refactor cycle is a TDD workflow where you write a failing test, implement the minimal production code to make it pass, and then clean up the code without changing its behavior.

To write minimal behavior-focused unit tests, name tests for specific outcomes and align assertions with real production code rather than mocks. This keeps tests precise and prevents testing mock behavior instead of actual software behavior.

Tests passing immediately indicates an anti-pattern where the test fails to capture missing behavior. You must ensure the test fails first to prove it targets the intended new code before making it pass.

Yes, you can use test-driven development for refactoring by starting with a test that demonstrates current behavior. This ensures your refactoring maintains behavioral correctness without introducing unexpected regressions.

Common TDD anti-patterns to avoid include writing tests after implementation, tests that pass immediately, and mocking the exact behavior you are asserting. These undermine test reliability and behavioral correctness.