tdd

Write one failing test that describes desired behavior through a public interface, then write only the minimal code needed to make it pass. Repeat one slice at a time, letting each test respond to what the previous cycle taught you.

A seam is the public boundary where you observe behavior without reaching inside the code. Tests live at seams, never against internals, and all seams under test should be agreed with the user before any test is written.

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 prefer dependency injection and SDK-style interfaces to make boundaries easy to mock.

Tests break during refactoring 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 they survive internal changes.

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, worked example, or specification.

No. Writing all tests first is horizontal slicing, which verifies imagined behavior and commits to test structure prematurely. Work in vertical slices instead: one failing test, one minimal implementation, then repeat.