tdd

Start by agreeing on the seams, the public interfaces where tests will live, then write one failing test, implement just enough code to pass it, and repeat. Work in vertical slices of one test and one implementation per cycle rather than writing all tests upfront.

A seam is the public boundary where you observe behavior without reaching inside the code. Tests live at seams and never against internals, so they survive refactors. Before writing tests, write down the seams under test and confirm them with the user.

Mock only at system boundaries such as external APIs, databases, time, randomness, and the file system. Never mock your own classes or internal collaborators. Use dependency injection and SDK-style interfaces so each mock returns one specific shape.

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 the expected value the same way the code does, so it passes by construction and can never catch a bug. Expected values must come from an independent source such as a known literal, a worked example, or the specification.