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 loop 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 when implementation changes without any behavior change.

Mock only at system boundaries such as external APIs, payment gateways, time, and randomness. Never mock your own classes or internal collaborators, and prefer dependency injection so boundary dependencies can be passed in and substituted.

Writing all tests first is horizontal slicing, which produces tests of imagined behavior coupled to guessed structure. Vertical tracer-bullet slices let each test respond to what the previous cycle revealed about the actual implementation.

Accept dependencies as parameters instead of constructing them internally, return results instead of producing side effects, and keep the surface area small. Fewer methods and simpler parameters mean fewer tests and simpler setup.