tdd

Start by agreeing on the seams, the public interfaces where tests will live, then write one failing test that describes observable behavior. Implement only enough code to make it pass, then repeat with the next vertical slice instead of writing all tests upfront.

Red-green means writing a failing test first, then the minimal code to pass it. This Skill treats refactoring as a separate review-stage activity, not part of the implementation loop, keeping each cycle focused on one behavior.

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 plus SDK-style interfaces to keep mocks simple.

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

A tautological test computes its 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.