tdd

Use this skill when

• •Implementing new features or fixing bugs using test-driven development
• •You need strict red-green-refactor cycle enforcement
• •Coordinating multi-phase TDD workflows

Do not use this skill when

• •The task is exploratory or spike work (TDD after spike)
• •UI layout-only changes with no testable logic
• •The task is unrelated to writing or modifying code

Instructions

Follow strict RED-GREEN-REFACTOR discipline. Each phase must complete before the next begins. Reference resources/red-green-refactor.md for phase-specific patterns and resources/implementation-playbook.md for detailed examples.

Quick Reference: The TDD Cycle

RED    → Write a failing test that defines expected behavior
         ↓
GREEN  → Write the minimum code to make it pass
         ↓
REFACTOR → Improve code quality while keeping tests green
         ↓
        Repeat...

Three Laws of TDD

1. •Write production code only to make a failing test pass
2. •Write only enough test to demonstrate failure
3. •Write only enough code to make the test pass

Test Pattern (AAA)

Phased Workflow

Phase 1: Test Specification and Design

1. •Requirements Analysis — Analyze requirements, define acceptance criteria, identify edge cases, create test scenarios.
2. •Test Architecture — Design test structure, fixtures, mocks, and test data strategy.

Phase 2: RED — Write Failing Tests

1. •Write Unit Tests (Failing) — Write failing tests covering happy paths, edge cases, and error scenarios. DO NOT implement production code.
2. •Verify Test Failure — Confirm all tests fail for the right reasons (missing implementation, not syntax errors). No false positives.

Gate: Do not proceed until all tests fail appropriately.

Phase 3: GREEN — Make Tests Pass

1. •Minimal Implementation — Write the minimum code to make tests pass. No extra features or optimizations.
2. •Verify Test Success — Run all tests, confirm they pass, check coverage metrics.

Gate: All tests must pass before proceeding.

Phase 4: REFACTOR — Improve Code Quality

1. •Code Refactoring — Apply SOLID principles, remove duplication, improve naming. Run tests after each change.
2. •Test Refactoring — Remove test duplication, improve names, extract fixtures. Coverage must be maintained.

Phase 5: Integration Tests

1. •Write Integration Tests (Failing First) — Test component interactions, API contracts, data flow.
2. •Implement Integration — Make integration tests pass.

Phase 6: Continuous Improvement

1. •Performance and Edge Case Tests — Add stress tests, boundary tests, error recovery tests.
2. •Final Review — Verify TDD process was followed, check code and test quality.

Validation Checkpoints

RED Phase

• • All tests written before implementation
• • All tests fail with meaningful error messages
• • Failures are due to missing implementation
• • No test passes accidentally

GREEN Phase

• • All tests pass
• • No extra code beyond test requirements
• • Coverage meets thresholds (80% line, 75% branch)
• • No test was modified to make it pass

REFACTOR Phase

• • All tests still pass after refactoring
• • Code complexity reduced
• • Duplication eliminated
• • Test readability improved

Configuration Thresholds

Modes

Incremental (default)

1. •Write ONE failing test
2. •Make ONLY that test pass
3. •Refactor if needed
4. •Repeat for next test

Suite

1. •Write ALL tests for a feature (failing)
2. •Implement code to pass ALL tests
3. •Refactor entire module
4. •Add integration tests

Anti-Patterns to Avoid

Failure Recovery

If TDD discipline is broken:

1. •STOP immediately
2. •Identify which phase was violated
3. •Rollback to last valid state
4. •Resume from correct phase
5. •Document lesson learned

When to Use TDD