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. Each cycle is one vertical slice responding to what the previous cycle taught you.

Red-green-refactor means writing a failing test first (red), then writing only enough code to make it pass (green). Refactoring is not part of this loop; it belongs to a separate code review stage after the implementation cycle.

Mock only at system boundaries such as external APIs, databases, time, randomness, and the file system. Never mock your own classes or internal collaborators, and use dependency injection to make boundary dependencies easy to substitute.

Tests break during refactors when they are coupled to implementation details, such as mocking internal collaborators, testing private methods, or asserting on call counts. Tests should verify behavior through public interfaces so internal changes leave them untouched.

A tautological test recomputes the expected value the same way the implementation 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.