test-driven-development

Test-driven development enforces writing a minimal failing test before implementation. The red-green-refactor workflow involves writing a failing test, implementing the smallest code change to pass it, then refactoring while keeping tests green to prevent regressions.

To start test-first development, write a failing unit test demonstrating the desired behavior, run it to confirm it fails for the expected reason, implement minimal code to pass, and refactor while keeping tests green.

Use test-driven development during refactors, feature additions, and behavior changes when you need confidence that behavior is specified, reproducible, and protected from future regressions by automated tests driving implementation.

Yes, test-driven development requires tests that exercise real code with minimal mocking. You must verify each failing test fails for the expected reason before coding to ensure behavior-driven development.

Test-first development forces you to specify behavior with failing tests before writing implementation, reducing design drift and preventing untested production code. Writing tests after implementation lacks the iterative verification that drives behavior-driven development.