test-driven-development

Test-driven development prevents software regressions by requiring a failing test to guide minimal production code changes. You verify each test fails for the expected reason, implement the smallest fix, then confirm it passes before refactoring.

The red-green-refactor cycle for unit tests involves writing a failing test, adding the smallest production code to make it pass, and refactoring only after achieving a clean green state. This disciplined iteration expands coverage safely.

To fix bugs using a test-first workflow, turn the discovered bug into a failing unit test that reproduces it. Then follow red-green-refactor to implement the fix, ensuring the test passes and preventing recurrence.

You should avoid mocks-only verification for TDD when correctness must be proven before implementation. The discipline requires verifying that tests fail for the right reason and pass with clean output, avoiding over-engineered code and fragile implementations.

Yes, you can define API behavior using test-first engineering by writing a failing test for the intended behavior upfront. This forces you to define the expected API behavior before writing any production code.

The best way to start TDD for a new feature is to write a single failing unit test for the intended behavior. Then add the smallest production code needed to make it pass, keeping the scope tight.