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 check for regressions. This Prove-It Pattern guarantees the bug existed and is now fixed.

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 mocks last. Mock only when the real dependency is too slow, non-deterministic, or has uncontrollable side effects like external APIs. Over-mocking produces tests that pass while production breaks.

Yes, the TDD cycle is universal across languages. Discover the repository's own tooling through files like package.json, pom.xml, pyproject.toml, go.mod, or Cargo.toml, and use its focused and full-suite test commands for every step.

Skip TDD for pure configuration changes, documentation updates, or static content with no behavioral impact. Any change that alters logic, fixes a bug, or could break existing 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) instead of interactions, so tests verify what the code does rather than how it does it.