tdd

Test-driven development starts by defining behavior-focused tests around public interfaces. You plan user-visible outcomes first, then drive minimal implementations incrementally through a red-green-refactor cycle, validating one test at a time.

Integration tests survive refactoring when validated through public interfaces rather than internal implementation details. Define tests around observable behavior and user-visible outcomes, keeping them stable across structural changes while resisting over-mocking.

Mocking in test-driven development should be limited to system boundaries. Apply boundary-only mocking to isolate external dependencies, while keeping tests focused on public-interface behavior to prevent brittle test suites.

The red-green-refactor cycle guides implementation by first writing a failing test for a specific behavior, creating a minimal implementation to pass it, and then improving code structure and eliminating duplication only after the test passes.

Test-driven development applies to bug fixes by writing a test that reproduces the bug as a failing behavior validation. You then implement the minimal fix to make it pass, ensuring the specific defect is covered by a stable public-interface test.

Tests break during refactoring when they validate internal implementation details rather than observable behavior. Writing public-interface tests focused on user-visible outcomes ensures stability across internal structural changes and module depth adjustments.