tdd

Test-driven development follows the red-green loop: write one failing test against a public interface, then write only enough code to make it pass. Work in vertical slices of one test and one implementation per cycle rather than writing all tests upfront.

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, since that couples tests to implementation details and breaks them during refactors.

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 team, which focuses testing effort on critical paths and complex logic.

Tests break on refactoring when they are coupled to implementation details, such as mocking internal collaborators, testing private methods, or asserting on call counts. Rewrite them to verify observable behavior through public interfaces instead.

A tautological test recomputes its expected value the same way the implementation does, so it passes by construction and can never catch bugs. Avoid this by deriving expected values from independent sources like known literals, worked examples, or the specification.