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 this cycle per behavior rather than writing all tests upfront.

No. Writing all tests first is horizontal slicing and produces tests of imagined behavior. Use vertical slices: one test, one implementation, repeat, so each test responds to what you learned from the previous cycle.

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or file systems. Never mock your own classes or internal collaborators, since that couples tests to implementation details.

Tests break during refactoring when they verify implementation details like private methods, mock call counts, or internal structure instead of observable behavior. Write integration-style tests through public interfaces so they survive internal changes.

Good tests describe what the system does through public APIs and survive refactors. Bad tests mock internal collaborators, assert on call order, bypass interfaces to check databases directly, or fail when behavior has not changed.