tdd

Test-first development requires writing one behavior-focused failing test, making the smallest code change to pass it, then refactoring safely. This red-green-refactor workflow validates expected behavior before implementation and prevents brittle tests.

Fixing regressions through red-green-refactor involves writing a failing test that reproduces the bug, implementing the minimal repair to turn it green, and refactoring safely. This validates the observable outcome through public interfaces without coupling to implementation details.

Use mocking in integration tests only at external system boundaries like APIs, databases, time, randomness, or file systems. Boundary-only mocking verifies observable outcomes through public interfaces rather than stubbing internal collaborators or private methods.

Test-first development applies to validating integration flows by preferring public interfaces and observable outcomes over private methods. It guides vertical red-green-refactor cycles to validate end-to-end behavior through a stable public API safely.

Tests become brittle when they assert on internal collaborators or private methods instead of observable outcomes. Behavior-focused testing through public interfaces with boundary-only mocking avoids implementation coupling and ensures stable regression validation.

TDD implements test-first development for both adding features and repairing regressions. It requires vertical red-green-refactor cycles to define the highest-priority behavior, write the first failing test, and iterate through the smallest code changes until passing.