TDD Implementation — Feature-Driven Test-First Development
You are implementing a feature or fixing a bug using strict Test-Driven Development. This is a more structured workflow than /tdd — you analyze the requirement, break it into testable behaviors, and implement each one through a full Red-Green-Refactor cycle.
Input
$ARGUMENTS
Step 1: Analyze the Requirement
Actions
- Read the requirement carefully — identify what behavior needs to change or be added
- Find relevant source code: Use Grep/Glob to locate the files that need to change
- Read existing tests: Find any existing test coverage for the affected code
- Identify testable behaviors: Break the requirement into 1-5 discrete, testable units
Output
## Requirement Analysis
**Requirement**: [one-line summary]
**Source files**: [list of files that will be modified]
**Existing tests**: [list of related test files, or "none found"]
**Testable behaviors**:
1. [behavior 1 — what it does, how to verify]
2. [behavior 2 — what it does, how to verify]
3. [behavior 3 — if needed]
Step 2: Implement Each Behavior via TDD
For EACH testable behavior, execute a full Red-Green-Refactor cycle:
RED: Write Failing Test
- Write a minimal test for this specific behavior
- Follow all conventions from
agents/tests.md:FL_prefixed macros (FL_CHECK_EQ,FL_REQUIRE_TRUE, etc.)- Include
test.handFastLED.h using namespace fl;+ anonymous namespace- Mirror source path for test file placement
- Run
bash test TestName— verify it FAILS for the right reason
GREEN: Minimal Implementation
- Write the minimum code to make this test pass
- Do NOT implement other behaviors yet
- Run
bash test TestName— verify it PASSES - Run
bash test --cpp— verify no regressions
REFACTOR: Clean Up
- Improve code quality without changing behavior
- Run tests after each change to verify they stay green
Report Each Cycle
### Behavior N: [description]
- RED: Test written at tests/fl/foo.cpp — FAILS (expected: [reason])
- GREEN: Implemented in src/fl/foo.h — PASSES
- REFACTOR: [changes made, or "clean as-is"]
Step 3: Integration Verification
After all behaviors are implemented:
- Run full test suite:
bash test --cpp - Check for regressions: Verify ALL tests pass, not just new ones
- Review changes holistically: Ensure the implementation is cohesive
- Run code review: Check changes against FastLED coding standards
Output
## Integration Verification
**Full test suite**: [X/X] tests pass
**New tests added**: [count]
**Source files modified**: [list]
**Regressions**: None / [details if any]
Step 4: Final Summary
## TDD Implementation Complete
**Requirement**: [what was implemented]
**Approach**: [brief description of the solution]
### Files Changed
| File | Change Type | Description |
|------|-------------|-------------|
| tests/fl/foo.cpp | Added | 3 test cases for [feature] |
| src/fl/foo.h | Modified | Added [function/method] |
### Test Coverage
- [Test case 1]: [what it verifies]
- [Test case 2]: [what it verifies]
- [Test case 3]: [what it verifies]
### All Tests Passing: Yes
Key Rules
- Test FIRST, implement SECOND — this order is absolute
- One behavior per cycle — don't batch multiple behaviors
- Minimal implementation — write the simplest code that passes
- Run tests at EVERY transition — RED->GREEN->REFACTOR each verified
- Stay in project root — never
cdto subdirectories - Use
bash testwrapper — never barepython,meson, orninja - Extend existing test files — don't create new ones unless necessary
- No mocks — use real objects and values