tdd

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

Good tests verify behavior through public interfaces and survive refactors, like "user can checkout with valid cart". Bad tests mock internal collaborators, test private methods, or recompute expected values the same way the implementation does.

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.

Tests break during refactoring when they are coupled to implementation details, such as asserting on internal method calls or verifying through side channels like direct database queries. Rewrite them to verify outcomes through the public interface instead.

A tautological test computes its expected value the same way the code under test 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 or worked example.