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 tests green. The cycle repeats for each new behavior.

Prefer real implementations first, then fakes, stubs, and finally interaction mocks. Reserve mocks for dependencies that are slow, non-deterministic, or have uncontrollable side effects like external APIs or email sending.

Skip TDD for pure configuration changes, documentation updates, or static content changes with no behavioral impact. Any change that alters logic or behavior should start with a failing test.

Tests that assert on internal method calls or implementation details break during refactoring even when behavior is unchanged. Assert on inputs and outputs (state-based testing) instead of interaction sequences.

Follow the test pyramid: roughly 80% unit tests, 15% integration tests, and 5% E2E tests. Limit E2E tests to critical user flows since they are slow and expensive to maintain.