Overview

Test-Driven Development (TDD) starts by writing a failing test that encodes the desired behavior, then writing the minimal production code to pass. The core principle is that production code should not exist without a failing test first. It follows the RED-GREEN-REFACTOR cycle and encourages frequent small commits to safeguard quality.

How This Skill Works

TDD uses a strict RED-GREEN-REFACTOR loop: RED (write a failing test), VERIFY RED (confirm the right failure), GREEN (write the simplest code to pass), VERIFY GREEN (run the full suite), REFACTOR (clean up while keeping tests green), and COMMIT (frequent small commits). The Iron Law enforces NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.

When to Use It

• When starting a new feature or user story
• When fixing a bug to capture the exact failing behavior
• When changing an API or contract to ensure it’s tested first
• When refactoring a module to improve design without changing behavior
• When adding regression tests for known edge cases or flaky paths

Quick Start

1. Step 1: Write one failing test showing the desired behavior
2. Step 2: Run tests to verify the failure (RED)
3. Step 3: Implement the simplest code to pass, run full tests, refactor, and commit frequently

Best Practices

• Write the failing test first that encodes the desired behavior
• Run the test to verify the failure before coding
• Implement only what's necessary to pass (YAGNI)
• Run the full test suite and refactor while keeping tests green
• Commit frequently in small, focused changes

Example Use Cases

• Creating a new feature by failing a test first, then implementing
• Bug fix with a reproducer test that fails until the fix is applied
• API evolution with tests that lock in the new contract
• Refactoring a billing module with preserved behavior via tests
• Adding regression tests for a flaky integration path

Frequently Asked Questions