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 one test at a time rather than writing all tests upfront, so each test responds to what you learned from the previous cycle.

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: external APIs, databases, time, randomness, and file systems. Never mock your own classes or internal collaborators. Design boundaries with dependency injection and SDK-style interfaces so each mock returns one specific shape.

Tests break on refactor 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, describing what the system does rather than how it does it.

No. Writing all tests first is horizontal slicing and produces tests of imagined behavior coupled to data shapes. Use vertical slices instead: one test, one implementation, repeated, so each test reflects real behavior you just built.