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 the cycle one behavior at a time 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, so they break 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 internal function names, private methods, or mock call expectations. Rewrite them to verify behavior through the public interface so internal restructuring leaves them untouched.

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