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 whenever implementation changes without behavior changing.

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 plus SDK-style interfaces to make boundary mocking straightforward.

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.