test-driven-development

Test-Driven Development

A disciplined approach to development where tests drive the design and implementation of code.

When to Use

Use this skill when:

• Implementing new features
• Fixing bugs (write test first to capture bug)
• Refactoring existing code
• Building new modules or components
• Writing library code

The TDD Cycle

The Three Laws of TDD

1. Red: Write a failing test before writing production code
2. Green: Write the minimal code to make the test pass
3. Refactor: Clean up the code while keeping tests green

Visual Workflow

┌─────────┐
│   RED   │ ──► Write failing test
└────┬────┘
     │
     ▼
┌─────────┐
│  GREEN  │ ──► Write minimal code to pass
└────┬────┘
     │
     ▼
┌──────────┐
│ REFACTOR │ ──► Improve code quality
└─────┬────┘
      │
      └──► Repeat

Phase 1: RED - Write Failing Test

Goal: Write a test that fails because the feature doesn't exist yet

Steps

1. Understand the requirement

   • What should the code do?
   • What are the inputs and outputs?
   • What are the edge cases?

2. Write a minimal test

   • Test one thing only
   • Use descriptive test name
   • Focus on behavior, not implementation

3. Run the test

   • Verify it fails for the right reason
   • The test should fail, not crash
   • Error message should be informative

Test Template

#[test]
fn test_<behavior_description>() {
    // Arrange - Set up test data
    let input = /* test input */;
    let expected = /* expected output */;
    
    // Act - Execute the behavior
    let result = function_under_test(input);
    
    // Assert - Verify the outcome
    assert_eq!(result, expected);
}

Examples

// ✅ Good: Test behavior with descriptive name
#[test]
fn test_calculate_total_returns_sum_of_item_prices() {
    let items = vec![
        Item { name: "A", price: 10.0 },
        Item { name: "B", price: 20.0 },
    ];
    
    let result = calculate_total(&items);
    
    assert_eq!(result, 30.0);
}

// ✅ Good: Test edge case
#[test]
fn test_calculate_total_returns_zero_for_empty_items() {
    let items = vec![];
    
    let result = calculate_total(&items);
    
    assert_eq!(result, 0.0);
}

// ✅ Good: Test error case
#[test]
fn test_parse_config_returns_error_for_invalid_toml() {
    let invalid_toml = "not valid toml [[[";
    
    let result = parse_config(invalid_toml);
    
    assert!(result.is_err());
    assert!(matches!(result.unwrap_err(), ConfigError::InvalidToml(_)));
}

// ❌ Bad: Testing implementation details
#[test]
fn test_internal_parser_helper() {
    // Don't test private functions directly
}

// ❌ Bad: Multiple assertions in one test
#[test]
fn test_everything() {
    assert_eq!(func1(), 1);
    assert_eq!(func2(), 2);
    assert_eq!(func3(), 3);  // If func2 fails, we don't test func3
}