test-driven-development

Test-driven development (TDD) writes failing tests first, then minimal code to pass them. This ensures tests verify actual behavior, preventing hidden bugs and regressions that plague post-hoc testing approaches.

Red-green-refactor is TDD's core cycle: write a failing test (red), write minimal code to pass it (green), then refactor for quality. This discipline ensures every line of production code is validated by a test that proved it was necessary.

Observing a test fail before implementation proves the test actually verifies your intended behavior rather than passing by accident. This prevents false confidence and ensures regressions are caught when behavior changes.

TDD applies to new features, bug fixes, refactoring, and behavior changes. Write a failing test that reproduces the bug or specifies desired behavior, then implement minimal code to pass it, ensuring the fix is validated and won't regress.

Avoid writing code before tests, testing implementation details through mocks instead of behavior, and writing tests after code. These patterns defeat TDD's purpose of preventing bugs and building confidence through test-first discipline.

Test-first development builds a suite of behavior specifications before implementation. Each test validates one requirement, creating a safety net that catches regressions when code changes and prevents bugs from silently emerging.