/tdd

TDD Command

Enforce test-driven development methodology for the requested feature or fix.

Workflow

1. Scaffold Interfaces - Define types/interfaces first
2. Generate Tests First - Write failing tests (RED)
3. Implement Minimal Code - Write just enough to pass (GREEN)
4. Refactor - Improve code while keeping tests green (REFACTOR)
5. Verify Coverage - Ensure 80%+ test coverage

When to Use

Use /tdd when:

• Implementing new features
• Adding new functions/components
• Fixing bugs (write test that reproduces bug first)
• Refactoring existing code
• Building critical business logic

TDD Cycle

RED -> GREEN -> REFACTOR -> REPEAT

RED:      Write a failing test
GREEN:    Write minimal code to pass
REFACTOR: Improve code, keep tests passing
REPEAT:   Next feature/scenario

Process

1. Define interfaces for inputs/outputs
2. Write tests that will FAIL (because code doesn't exist yet)
3. Run tests and verify they fail for the right reason
4. Write minimal implementation to make tests pass
5. Run tests and verify they pass
6. Refactor code while keeping tests green
7. Check coverage and add more tests if below 80%

TDD Best Practices

DO:

• Write the test FIRST, before any implementation
• Run tests and verify they FAIL before implementing
• Write minimal code to make tests pass
• Refactor only after tests are green
• Add edge cases and error scenarios
• Aim for 80%+ coverage (100% for critical code)

DON'T:

• Write implementation before tests
• Skip running tests after each change
• Write too much code at once
• Ignore failing tests
• Test implementation details (test behavior)
• Mock everything (prefer integration tests)

Test Types to Include

Unit Tests (Function-level):

• Happy path scenarios
• Edge cases (empty, null, max values)
• Error conditions
• Boundary values

Integration Tests (Component-level):

• API endpoints
• Database operations
• External service calls
• Components with hooks/services