|
| 1 | +# TDD Implementation Workflow |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The TDD implementation workflow orchestrates a strict Test-Driven Development process through three specialized agents: |
| 6 | + |
| 7 | +1. **Test Condition Architect** - Collaborates with you to define test requirements in plain language |
| 8 | +2. **Test Builder** - Transforms requirements into executable test suites |
| 9 | +3. **Implementation Specialist** - Writes minimal code to make tests pass, module by module |
| 10 | + |
| 11 | +## Workflow Architecture |
| 12 | + |
| 13 | +```mermaid |
| 14 | +graph TD |
| 15 | + A[Issue/Task] --> B[Test Condition Definition] |
| 16 | + B --> C{User Review} |
| 17 | + C -->|Approved| D[Test Generation] |
| 18 | + C -->|Needs Changes| B |
| 19 | + D --> E[Red Phase - Tests Fail] |
| 20 | + E --> F[Implementation Module 1] |
| 21 | + F --> G[Tests Pass?] |
| 22 | + G -->|No| F |
| 23 | + G -->|Yes| H[Implementation Module 2] |
| 24 | + H --> I[All Modules Complete] |
| 25 | + I --> J[Refactor Phase] |
| 26 | + J --> K[Final Validation] |
| 27 | + K --> L[Ready for Review] |
| 28 | +``` |
| 29 | + |
| 30 | +## Integration with Development Lifecycle |
| 31 | + |
| 32 | +### 1. Planning Phase (`/plan:refine-issue`) |
| 33 | +- Collaboratively explore and refine requirements |
| 34 | +- Make architectural decisions |
| 35 | +- Create ADRs for significant choices |
| 36 | +- Output: Clear requirements and approach |
| 37 | + |
| 38 | +### 2. Implementation Phase (`/implement:tdd-implement`) |
| 39 | +**← THIS WORKFLOW** |
| 40 | +- Transform requirements into test conditions |
| 41 | +- Generate comprehensive test suite |
| 42 | +- Implement code to pass tests |
| 43 | +- Refactor for quality |
| 44 | +- Output: Fully tested, working code |
| 45 | + |
| 46 | +### 3. Review Phase (`/review:pr-review`) |
| 47 | +- Comprehensive code review |
| 48 | +- Architecture compliance check |
| 49 | +- Test coverage validation |
| 50 | +- Pattern Stack integration opportunities |
| 51 | +- Output: Validated, production-ready code |
| 52 | + |
| 53 | +## Key Principles |
| 54 | + |
| 55 | +### Strict TDD Cycle |
| 56 | +1. **Red**: Write tests that fail (no implementation yet) |
| 57 | +2. **Green**: Write minimal code to pass tests |
| 58 | +3. **Refactor**: Improve code while keeping tests green |
| 59 | + |
| 60 | +### Module-by-Module Approach |
| 61 | +- Complete one module entirely before starting the next |
| 62 | +- Maintain working state after each module |
| 63 | +- Track progress granularly in TodoWrite |
| 64 | + |
| 65 | +### Collaborative Definition |
| 66 | +- Work WITH the user to understand requirements |
| 67 | +- Define test conditions in GIVEN-WHEN-THEN format |
| 68 | +- Get explicit approval before proceeding |
| 69 | + |
| 70 | +### Quality Gates |
| 71 | +- Every module must achieve >80% test coverage |
| 72 | +- All tests must pass before moving forward |
| 73 | +- Linting, type checking, and formatting must be clean |
| 74 | +- Performance benchmarks must be acceptable |
| 75 | + |
| 76 | +## Command Usage |
| 77 | + |
| 78 | +### Basic Usage |
| 79 | +```bash |
| 80 | +# Implement a specific issue |
| 81 | +claude-code /implement:tdd-implement CLI-8 |
| 82 | + |
| 83 | +# Implement current work (auto-detects from git/Linear) |
| 84 | +claude-code /implement:tdd-implement |
| 85 | +``` |
| 86 | + |
| 87 | +### Workflow Progression |
| 88 | +1. **Start**: Command identifies the task from Linear or git |
| 89 | +2. **Collaborate**: Work with user to define test conditions |
| 90 | +3. **Generate**: Create comprehensive test suite |
| 91 | +4. **Implement**: Build features module by module |
| 92 | +5. **Refactor**: Optimize while maintaining green tests |
| 93 | +6. **Complete**: Prepare for review phase |
| 94 | + |
| 95 | +## Agent Orchestration |
| 96 | + |
| 97 | +The workflow uses parallel agent execution where beneficial: |
| 98 | + |
| 99 | +### Sequential Phases |
| 100 | +- Test condition definition (needs user collaboration) |
| 101 | +- Test generation (depends on conditions) |
| 102 | +- Module implementation (one at a time for clarity) |
| 103 | + |
| 104 | +### Parallel Execution |
| 105 | +- Final validation (lint, typecheck, tests, security) |
| 106 | +- Refactoring analysis across modules |
| 107 | +- Documentation updates |
| 108 | + |
| 109 | +## Output Artifacts |
| 110 | + |
| 111 | +### Test Specifications |
| 112 | +- `tests/test_specs/[issue-id]-test-specification.md` |
| 113 | +- Documents all test conditions and acceptance criteria |
| 114 | + |
| 115 | +### Test Suite |
| 116 | +- Comprehensive tests following project patterns |
| 117 | +- Organized by module/component |
| 118 | +- Includes unit, integration, and performance tests |
| 119 | + |
| 120 | +### Implementation |
| 121 | +- Minimal code that passes all tests |
| 122 | +- Follows project architectural patterns |
| 123 | +- Properly typed and documented |
| 124 | + |
| 125 | +### Documentation |
| 126 | +- Updated CLAUDE.md if patterns change |
| 127 | +- Feature documentation in docs/ |
| 128 | +- API documentation if applicable |
| 129 | + |
| 130 | +## Success Metrics |
| 131 | + |
| 132 | +A successful TDD implementation will have: |
| 133 | +- ✅ 100% of defined test conditions covered |
| 134 | +- ✅ All tests passing |
| 135 | +- ✅ >80% code coverage |
| 136 | +- ✅ Clean linting and type checking |
| 137 | +- ✅ Documentation updated |
| 138 | +- ✅ Ready for PR review |
| 139 | + |
| 140 | +## Tips for Effective Use |
| 141 | + |
| 142 | +1. **Be Thorough in Test Definition**: Missing test conditions lead to bugs |
| 143 | +2. **Think Like a User**: Consider edge cases and error scenarios |
| 144 | +3. **Work Incrementally**: Small, atomic changes are easier to debug |
| 145 | +4. **Trust the Process**: Don't skip steps or write code before tests |
| 146 | +5. **Communicate Continuously**: Flag concerns early, don't wait |
| 147 | + |
| 148 | +## Related Commands |
| 149 | + |
| 150 | +- **Before**: Use `/plan:refine-issue` to clarify requirements |
| 151 | +- **After**: Use `/review:pr-review` to validate implementation |
| 152 | +- **During**: Track progress with TodoWrite tool |
| 153 | + |
| 154 | +## Future Enhancements |
| 155 | + |
| 156 | +As this workflow matures, we plan to: |
| 157 | +- Add specialized agents for specific domains (API, UI, CLI) |
| 158 | +- Integrate performance profiling into the cycle |
| 159 | +- Add mutation testing for test quality validation |
| 160 | +- Create domain-specific test generators |
| 161 | +- Add automatic test data generation |
0 commit comments