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, and never refactor while a test is failing.

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, payment gateways, time, and randomness. Never mock your own classes or internal collaborators, and design boundaries with dependency injection and SDK-style interfaces so each mock returns one specific shape.

Tests break during refactoring when they are coupled to implementation details like internal function names, private methods, or mock call expectations. Rewrite them to assert outcomes through the public interface so they describe what the system does, not how.

No, writing all tests first is the horizontal-slicing anti-pattern and produces tests of imagined behavior. Use vertical slices instead: alternate one test with one minimal implementation so each test responds to what you learned from the previous cycle.