agents/tools/tdd-red.md

model

model
sonnet

Write comprehensive failing tests following TDD red phase principles:

[Extended thinking: This tool uses the test-automator agent to generate comprehensive failing tests that properly define expected behavior. It ensures tests fail for the right reasons and establishes a solid foundation for implementation.]

Test Generation Process

Use Task tool with subagent_type="test-automator" to generate failing tests.

Prompt: "Generate comprehensive FAILING tests for: $ARGUMENTS. Follow TDD red phase principles:

1. Test Structure Setup

   • Choose appropriate testing framework for the language/stack
   • Set up test fixtures and necessary imports
   • Configure test runners and assertion libraries
   • Establish test naming conventions (should_X_when_Y format)

2. Behavior Definition

   • Define clear expected behaviors from requirements
   • Cover happy path scenarios thoroughly
   • Include edge cases and boundary conditions
   • Add error handling and exception scenarios
   • Consider null/undefined/empty input cases

3. Test Implementation

   • Write descriptive test names that document intent
   • Keep tests focused on single behaviors (one assertion per test when possible)
   • Use Arrange-Act-Assert (AAA) pattern consistently
   • Implement test data builders for complex objects
   • Avoid test interdependencies - each test must be isolated

4. Failure Verification

   • Ensure tests actually fail when run
   • Verify failure messages are meaningful and diagnostic
   • Confirm tests fail for the RIGHT reasons (not syntax/import errors)
   • Check that error messages guide implementation
   • Validate test isolation - no cascading failures

5. Test Categories

   • Unit Tests: Isolated component behavior
   • Integration Tests: Component interaction scenarios
   • Contract Tests: API and interface contracts
   • Property Tests: Invariants and mathematical properties
   • Acceptance Tests: User story validation

6. Framework-Specific Patterns

   • JavaScript/TypeScript: Jest, Mocha, Vitest patterns
   • Python: pytest fixtures and parameterization
   • Java: JUnit5 annotations and assertions
   • C#: NUnit/xUnit attributes and theory data
   • Go: Table-driven tests and subtests
   • Ruby: RSpec expectations and contexts

7. Test Quality Checklist ✓ Tests are readable and self-documenting ✓ Failure messages clearly indicate what went wrong ✓ Tests follow DRY principle with appropriate abstractions ✓ Coverage includes positive, negative, and edge cases ✓ Tests can serve as living documentation ✓ No implementation details leaked into tests ✓ Tests use meaningful test data, not 'foo' and 'bar'

8. Common Anti-Patterns to Avoid

   • Writing tests that pass immediately
   • Testing implementation instead of behavior
   • Overly complex test setup
   • Brittle tests tied to specific implementations
   • Tests with multiple responsibilities
   • Ignored or commented-out tests
   • Tests without clear assertions

Output should include:

• Complete test file(s) with all necessary imports
• Clear documentation of what each test validates
• Verification commands to run tests and see failures
• Metrics: number of tests, coverage areas, test categories
• Next steps for moving to green phase"

Validation Steps

After test generation:

1. Run tests to confirm they fail
2. Verify failure messages are helpful
3. Check test independence and isolation
4. Ensure comprehensive coverage
5. Document any assumptions made

Recovery Process

If tests don't fail properly:

• Debug import/syntax issues first
• Ensure test framework is properly configured
• Verify assertions are actually checking behavior
• Add more specific assertions if needed
• Consider missing test categories

Integration Points

• Links to tdd-green.md for implementation phase
• Coordinates with tdd-refactor.md for improvement phase
• Integrates with CI/CD for automated verification
• Connects to test coverage reporting tools

Best Practices

• Start with the simplest failing test
• One behavior change at a time
• Tests should tell a story of the feature
• Prefer many small tests over few large ones
• Use test naming as documentation
• Keep test code as clean as production code

Test requirements: $ARGUMENTS