tdd

Write one failing test for a single behavior (red), write the minimal code to make it pass (green), then refactor while tests stay green. Repeat per behavior rather than writing all tests first, so each test responds to what you learned from the previous cycle.

Good tests verify observable behavior through public interfaces and survive internal refactors. Bad tests mock internal collaborators, test private methods, or assert on call counts, so they break whenever implementation changes even though behavior stays the same.

Mock only at system boundaries such as external APIs, databases, time, randomness, and the file system. Never mock your own classes or internal collaborators, and use dependency injection plus SDK-style interfaces to make boundary mocks simple.

Writing all tests first is horizontal slicing, which produces tests of imagined behavior and data shapes rather than real behavior. Vertical tracer-bullet slices, one test then one implementation, keep tests aligned with actual system behavior.

A deep module pairs a small interface with substantial hidden implementation, from A Philosophy of Software Design. Deep modules reduce the surface area tests must cover, making behavior-focused tests easier to write and more stable across refactors.