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.

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, breaking whenever implementation changes without behavior changing.

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 are coupled to implementation details like private methods, internal mocks, or call-order assertions. Rewrite them to verify behavior through public interfaces so they describe what the system does, not how.

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