Test-Driven Development

Philosophy

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

Good tests are integration-style: they exercise real code paths through public APIs and describe what the system does, not how. These tests survive refactors because they don't care about internal structure.

Bad tests are coupled to implementation — mocking internal collaborators, testing private methods, or verifying via external means (e.g. querying the database directly instead of through the interface). Warning sign: your test breaks when you refactor but behavior hasn't changed.

See references for examples and guidelines.

Reference Guide