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 changes.

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, and prefer dependency injection to make boundaries mockable.

Writing all tests first (horizontal slicing) produces tests of imagined behavior coupled to data shapes and signatures. Vertical slices with one test then one implementation let each test respond to what you learned from the previous cycle.

Refactor only after all tests pass, never while red. Look for duplication, long methods, shallow modules, feature envy, and primitive obsession, running tests after each refactor step.