test-driven-development

Write a test that reproduces the bug first and confirm it fails, then implement the fix and confirm the test passes. Finally run the full test suite to verify no regressions were introduced.

Red means writing a failing test for the desired behavior, green means writing the minimal code to make it pass, and refactor means cleaning up the implementation while keeping all tests passing.

Prefer real implementations first, then fakes, stubs, and mocks last. Use mocks only when the real dependency is too slow, non-deterministic, or has uncontrollable side effects like external APIs or email sending.

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

Tests likely assert on internal implementation details or method call sequences instead of outcomes. Test state and inputs/outputs rather than interactions so refactoring without behavior change keeps tests green.

Follow the test pyramid: roughly 80% fast unit tests for pure logic, 15% integration tests for API and database boundaries, and 5% end-to-end tests limited to critical user flows.