test-driven-development

Write a test that reproduces the bug and confirm it fails before touching the implementation. Then implement the fix, watch the test pass, and run the full test suite to verify no regressions were introduced.

Red means writing a test that fails because the behavior doesn't exist yet. Green means writing the minimum code to make it pass. Refactor means cleaning up the implementation while keeping all tests passing.

Prefer real implementations first, then fakes, stubs, and finally mocks as a last resort. Mock only at boundaries where real dependencies are slow, non-deterministic, or have uncontrollable side effects like external APIs.

Skip tests only for pure configuration changes, documentation updates, or static content with no behavioral impact. Any change to logic, behavior, or edge case handling should have a corresponding test.

Tests break during refactoring when they verify internal method calls instead of outcomes. Test state and behavior through inputs and outputs rather than interaction-based assertions on implementation details.