tdd

Test-driven development begins by identifying public interfaces, or seams, to test behavior. You define the expected behavior at these boundaries before writing any implementation, ensuring clean architectural separation and refactor-resilient code.

The red-green-refactor loop is a strict test-driven development cycle. You write a failing behavior test (red), implement the minimum code to pass it (green), and then refactor the code separately to maintain high test coverage and clean boundaries.

Mocking should be used exclusively at system boundaries. You design for mockability using dependency injection to replace external dependencies, avoiding implementation-detail mocking that couples tests to internal code structure.

Refactor-resilient tests focus on behavior at defined system seams rather than internal implementation details. By avoiding implementation-coupled assertions and tautological tests, your unit tests remain valid during code refactoring.

Test-driven development applies to refactoring tasks by guiding the creation of behavior-focused tests at defined seams. This enforces a disciplined cycle that prevents implementation-coupled tests and ensures high test coverage before modifying existing logic.

Unit tests break during refactoring when they are coupled to internal implementation details rather than public behavior. By testing defined system seams and avoiding implementation-detail mocking, you prevent tautological assertions and maintain refactor-resilient code.