test-driven-development

Start with a failing acceptance test at the system boundary, then unit-test the outermost object while mocking collaborators it needs. Implement each mocked collaborator inward with its own test loop until the acceptance test passes against real implementations.

Solitary tests isolate one class with every collaborator mocked, while sociable tests use real internal collaborators and mock only at architectural seams like I/O. Sociable tests survive internal refactoring; solitary tests break when class boundaries change.

Mock collaborators performing I/O, those whose interaction is the behavior under test, unimplemented collaborators in outside-in flow, and slow or non-deterministic dependencies. Never mock value objects, DTOs, pure functions, or third-party libraries directly.

London (mockist) TDD tests object interactions and drives design through mocks, suiting outside-in development. Classical (Detroit) TDD tests state with real collaborators and lets design emerge from refactoring. Many practitioners blend both approaches.

Tests break on refactoring when they mock internal class boundaries or verify implementation details instead of observable behavior. Switch to sociable tests that mock only at architectural seams, so internal restructuring leaves test assertions intact.

Common pitfalls include writing tests after code, skipping the refactor step, mocking everything, testing implementation details, and tolerating slow suites. Also avoid tests that never fail, since an unverified test may test nothing.