test-driven-development

Write a test that reproduces the bug and confirm it fails before touching the fix. Then implement the minimal change until the test passes, and run the full suite to check for regressions. This Prove-It Pattern guarantees the fix works and guards against regression.

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 green, then repeating the loop.

Prefer real implementations first, then fakes, stubs, and mocks last. Mocks that verify internal method calls break during refactoring even when behavior is unchanged. Reserve mocks for slow, non-deterministic, or side-effecting dependencies 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 written first.

A test that passes immediately proves nothing and likely isn't testing what you think. Verify the test fails for the right reason before implementing, since a passing-first test may assert the wrong behavior or never execute the code under test.