Test-Driven Development

Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

"Tests are specifications written in code."

Philosophy

Good tests exercise real code paths through public APIs. They describe what the system does, not how it does it. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.

Bad tests are coupled to implementation. They mock internal collaborators, test private methods, verify through external means (querying a DB directly instead of using the interface). Warning sign: your test breaks when you refactor, but behavior hasn't changed.

Anti-Pattern: Horizontal Slices

DO NOT write all tests first, then all implementation. This is "horizontal slicing" — treating RED as "write all tests" and GREEN as "write all code."