| name | tdd |
| description | Test-driven development: write tests first, implement until they pass. Use when implementing features with complex logic that benefits from test-first approach. Triggers: "TDDで", "テスト駆動", "テストファーストで実装", "tdd", "バグを防ぎたい", "テストから書いて".
|
TDD Skill
Autonomous test-driven development. Write comprehensive tests FIRST, then implement until all tests pass. Prevents "Buggy First-Pass Implementations".
Workflow: Red → Green → Refactor
Phase 1: Understanding (READ)
-
Read existing codebase to understand:
- Current architecture and patterns
- Existing types and interfaces
- Testing patterns already in use
-
Identify edge cases that commonly cause bugs:
- Empty data / null values
- Boundary conditions (0, negative, max values)
- Sorting bias (alphabetical, temporal)
- Normalization edge cases (division by zero, all same values)
- Missing configuration (.env variables)
- Type mismatches (string vs number, undefined fields)
Phase 2: Test Design (RED)
BEFORE writing ANY implementation code:
-
Write comprehensive tests covering:
- Happy path (expected usage)
- Edge cases (empty, null, boundary)
- Error conditions (invalid input, missing config)
- Integration points (API calls, data flow)
-
Run tests — they should ALL FAIL:
npx vitest run <test-file>
pytest <test-file> -v
-
Verify tests fail for the right reasons:
- ✓ Function not implemented yet → correct
- ✗ Test itself is broken → fix the test
Phase 3: Implementation (GREEN)
-
Implement the feature — minimal code to make tests pass
-
Run tests iteratively after each change until ALL pass
-
Verify no regressions — run full test suite:
npx vitest run
Phase 4: Verify
- Build verification:
npm run build
npm run typecheck
Phase 5: Report
- Provide summary:
✓ RED: Wrote 8 tests (edge cases, normalization, sorting bias)
✓ GREEN: All 8 tests passing
✓ Build passed, no regressions
Files: src/utils/score.ts (+45), test/score.test.ts (+85, new)
Common Edge Cases to Always Test
Scoring/Ranking: empty dataset, all same values, single item, division by zero
Field References: wrong field name, undefined/null, type mismatches
Sorting: alphabetical bias, temporal bias, tie-breaking
Configuration: missing .env, dotenv not loaded, API keys unset
Important Rules
- NEVER write implementation before tests — core TDD principle
- NEVER skip edge case tests — these catch the most common bugs
- NEVER ask clarifying questions — make assumptions and document them
- DO iterate until 100% pass — partial success is not done
- DO run full test suite — catch regressions