tdd

Follow the red-green loop: write one failing test that describes behavior through 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.

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, never against private methods or internal collaborators.

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 prefer dependency injection with SDK-style interfaces for mockability.

A tautological test recomputes the expected value the same way the code does, so it passes by construction. Brittle tests mock internal collaborators or verify through side channels like direct database queries, breaking whenever you refactor without changing behavior.

No, writing all tests first is horizontal slicing and produces tests of imagined behavior. Instead use vertical slices: one failing test, one minimal implementation, then repeat, letting each cycle inform the next.