tdd

Test-driven development fixes brittle test suites by applying behavior-first, integration-style testing. You verify observable outcomes through public interfaces and mock only system boundaries, ensuring tests survive refactoring without coupling to internal implementation details.

The red-green-refactor loop drives implementation by writing one failing test, creating minimal code to pass it, then improving structure. You follow this cycle vertically using tracer bullets, writing one test at a time instead of batching tests first.

Mocking in test-driven development should be reserved strictly for system boundaries like external APIs, databases, time, randomness, and filesystems. Mocking internal components creates brittle tests that break during refactoring and obscure actual behavior.

Writing tests for unclear requirements using tracer bullets involves defining public behavior up front and implementing one vertical slice at a time. You write a single test, implement minimal code to pass, and refactor while keeping tests green.

Avoiding horizontal slicing in test-driven development prevents batching all tests before implementation. You write tests and implementation vertically slice by slice, ensuring each tracer bullet validates observable outcomes through public interfaces before moving forward.