tdd

Write one failing test that describes behavior through a public interface, then write only enough code to make it pass, and repeat one slice at a time. Refactoring belongs to a separate review stage, not the red-green cycle.

A good test verifies observable behavior through public APIs and survives internal refactors, like "user can checkout with valid cart". Bad tests mock internal collaborators, test private methods, or recompute expected values the same way the code does.

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or the file system. Never mock your own classes or internal collaborators, and use dependency injection with SDK-style interfaces to keep mocks simple.

A seam is the public boundary where you observe behavior without reaching inside the code. Tests should live only at pre-agreed seams confirmed with the user before writing any test, focusing effort on critical paths.

Tests break on refactor when they are coupled to implementation details, such as mocking internal collaborators or asserting on call counts. Rewrite them to verify behavior through public interfaces so internal structure can change freely.