tdd

Start by agreeing on the public seams to test, then write one failing test for a single behavior, implement only enough code to pass it, and repeat. Work in vertical slices rather than writing all tests before any implementation.

A seam is the public boundary where you observe behavior without reaching inside the code, such as an interface or API. Tests live at seams and never against internals, so they survive refactors that change implementation but not behavior.

Tests break on refactoring when they are implementation-coupled, meaning they mock internal collaborators, test private methods, or verify through side channels like direct database queries. Rewrite them against public interfaces so they verify behavior, not structure.

A tautological test recomputes the expected value the same way the code does, such as asserting add(a, b) equals a + b, so it passes by construction and can never catch a bug. Expected values must come from an independent source like a known-good literal or the specification.

No, writing all tests first is horizontal slicing and produces tests for imagined behavior that go insensitive to real changes. Use vertical slices instead: one test, one minimal implementation, then repeat, letting each cycle inform the next.

Refactoring is not part of the red-green implementation loop. It belongs to the review stage after the cycle completes, keeping the loop focused on one failing test and one minimal passing implementation at a time.