TDD Workflow Skill

Overview

Test-Driven Development workflow enforcement. This skill ensures code is written test-first, following the Red-Green-Refactor cycle for higher quality and fewer bugs.

Type

technique

When to Invoke

Trigger keywords: TDD, test-driven, tests first, test coverage, red-green-refactor, write tests

Trigger phrases:

• •"write tests for..."
• •"test-driven development"
• •"implement with TDD"
• •"tests first approach"

Core Mandate

Write the test BEFORE the implementation.

This is not optional. TDD produces better designs because:

• •Forces thinking about interface before implementation
• •Catches edge cases early
• •Creates documentation through tests
• •Enables safe refactoring

The Red-Green-Refactor Cycle

┌─────────────────────────────────────────┐
│                                         │
│    ┌─────┐      ┌───────┐      ┌──────┐ │
│    │ RED │ ───► │ GREEN │ ───► │REFAC-│ │
│    │     │      │       │      │ TOR  │ │
│    └─────┘      └───────┘      └──────┘ │
│       ▲                           │     │
│       └───────────────────────────┘     │
│                                         │
└─────────────────────────────────────────┘

1. RED: Write a Failing Test

Before writing ANY code:

1. •Define expected behavior
2. •Write test that expresses this behavior
3. •Run test - it MUST fail
4. •If test passes, you wrote the wrong test

# Example: Testing a function that doesn't exist yet
def test_add_numbers_returns_sum():
    result = add_numbers(2, 3)  # Function doesn't exist!
    assert result == 5

2. GREEN: Write Minimal Code to Pass

Write ONLY enough code to make the test pass:

• •No extra features
• •No optimizations
• •No "while I'm here" additions
• •Ugly code is fine (for now)

# Minimal implementation - just enough to pass
def add_numbers(a, b):
    return a + b

3. REFACTOR: Clean Up While Tests Pass

Now improve the code:

• •Remove duplication
• •Improve naming
• •Extract methods/functions
• •Run tests after EVERY change
• •If tests fail, you broke something - revert

Test Pyramid

          ┌──────────────┐
         /   E2E Tests    \     ← Few, slow, fragile
        /   (10% of tests)  \
       ├────────────────────┤
      /  Integration Tests    \  ← Some, moderate speed
     /    (20% of tests)        \
    ├────────────────────────────┤
   /      Unit Tests               \ ← Many, fast, stable
  /       (70% of tests)             \
 └─────────────────────────────────────┘

Unit Tests (70%)

• •Test single function/method
• •No external dependencies (DB, network, filesystem)
• •Fast (< 100ms each)
• •Use mocks for dependencies

Integration Tests (20%)

• •Test component interactions
• •May use test databases
• •Moderate speed (< 5s each)
• •Verify real integrations work

E2E Tests (10%)

• •Test full user flows
• •Use real (or realistic) environment
• •Slow but comprehensive
• •Catch integration issues

Coverage Requirements

Critical paths requiring 100% coverage:

• •Authentication/authorization
• •Payment processing
• •Data validation
• •Security-sensitive code

TDD Iteration Tracking

Track each TDD cycle (similar to Ralph technique):

Test Patterns

Arrange-Act-Assert (AAA)

def test_user_can_login():
    # Arrange: Set up test data
    user = create_test_user(email="test@example.com", password="secret")

    # Act: Perform the action
    result = login(email="test@example.com", password="secret")

    # Assert: Verify the outcome
    assert result.success is True
    assert result.user.email == "test@example.com"

Given-When-Then (BDD style)

def test_user_login():
    # Given a registered user
    user = create_test_user()

    # When they login with correct credentials
    result = login(user.email, user.password)

    # Then they should be authenticated
    assert result.is_authenticated()

Mocking Strategy

When to mock:

• •External services (APIs, databases)
• •Time-dependent code
• •Random/non-deterministic behavior
• •Slow operations

When NOT to mock:

• •The unit under test
• •Simple value objects
• •Pure functions

# Good: Mock external dependency
@patch('myapp.services.external_api.fetch')
def test_fetches_data(mock_fetch):
    mock_fetch.return_value = {"data": "test"}
    result = process_external_data()
    assert result == "processed: test"

# Bad: Mocking the thing you're testing
# Don't do this - tests nothing!

Edge Cases Checklist

Always test:

• • Empty input
• • Null/None values
• • Boundary values (0, -1, MAX_INT)
• • Invalid types
• • Very large inputs
• • Unicode/special characters
• • Concurrent access (if applicable)
• • Network failures (if applicable)
• • Timeout scenarios

Anti-Patterns

Integration with /newapp

When /newapp invokes this skill:

1. •Test framework setup included in project scaffold
2. •Example tests created
3. •Coverage configuration added
4. •CI pipeline includes test stage

Integration

Works with:

• •project-scaffolding - Test structure in new projects
• •systematic-debugging - Tests catch regressions
• •/newapp command - Invokes during implementation phase
• •/fix command - Write failing test before fix

Adapted from TDD principles by Kent Beck Anthropic-recommended workflow for Claude Code