test-driven-development

Write a test that reproduces the bug first and confirm it fails, then implement the fix and confirm the test passes. This Prove-It Pattern guarantees the fix works and guards against future regressions.

RED means writing a failing test that defines 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 mocks as a last resort. Mock only when the real dependency is too slow, non-deterministic, or has uncontrollable side effects like external APIs or email sending.

Yes, the TDD cycle is universal across languages. The workflow is identical once you discover the project's own tooling, whether that is Gradle, Cargo, pytest, Go, or a Makefile-based test command.

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

Over-mocking is the usual cause: tests that verify method calls instead of outcomes pass even when real behavior is broken. Test state and outputs rather than internal interactions, and prefer real implementations at boundaries.