tdd

Write one failing test for a single behavior (red), implement the minimal code to make it pass (green), then refactor while keeping tests green. Repeat this cycle per behavior instead of writing all tests upfront.

Good tests verify observable behavior through public APIs and survive internal refactoring. Bad tests mock internal dependencies, test private methods, or check call counts, causing failures when implementation changes but behavior does not.

Mock only at system boundaries such as external APIs, payment gateways, time, and randomness. Never mock your own classes or internal dependencies, and prefer dependency injection plus SDK-style interfaces to make boundary mocking straightforward.

Tests break during refactoring when they are coupled to implementation details like private methods, internal structure, or mock call verification. Rewrite them to assert behavior through public interfaces so they only fail when actual behavior changes.

No, writing all tests first is the horizontal slicing anti-pattern that produces tests for imagined behavior. Use vertical slicing instead: alternate one test with one implementation so each test reflects what you learned from the previous cycle.