| name | tdd |
| description | 用测试驱动开发方式实现或修复功能:先写失败测试,再做最小实现,最后重构。只在用户明确要求 TDD、先写测试、补回归测试或按 Red-Green-Refactor 工作时使用;不要用于单纯解释测试报错或泛泛讨论测试概念。 |
| user-invocable | true |
| disable-model-invocation | true |
| allowed-tools | Read, Grep, Glob, Write, Edit, Bash(npm:*, node:*, npx:*, vitest:*, jest:*, pytest:*) |
| argument-hint | [file-or-description] |
| compatibility | Works best in repositories with an existing test runner and established test conventions. |
TDD (Test-Driven Development) Skill
按小步快跑的 Red -> Green -> Refactor 循环工作,优先建立可复现的行为保护,再修改实现。
开始前
- 根据
$ARGUMENTS 明确目标行为、bug 场景或待实现功能。
- 先读现有实现、相邻测试和项目约定,优先沿用仓库已有的测试框架、fixture 和命名方式。
- 如果用户只要求“补测试”而没有要求改实现,就停在测试层,不主动改生产代码。
RED
- 写能暴露目标行为的最小失败测试。
- 对 bug 修复,先写复现 bug 的回归测试。
- 优先运行最小测试范围,确认它确实失败,并说明失败证明了什么。
GREEN
- 只做让新测试通过所需的最小实现改动。
- 先重跑刚刚失败的测试;必要时再补跑相邻测试。
- 不为了“顺手优化”扩大改动面。
REFACTOR
- 在测试保护下整理命名、消除重复、简化实现。
- 任何重构后都重新运行相关测试,确保行为不变。
- 只有在改动面较大或用户明确要求时,才扩大到更完整的测试集。
工作准则
- 优先断言对外可观察行为,而不是内部实现细节。
- 新增测试尽量贴近现有测试文件;只有在必要时才创建新文件。
- 如果仓库没有测试基础设施,先说明现状,再决定是补最小配置还是只给出建议。
- 不要把覆盖率数字当成目标;以行为信心和回归保护为准。
汇报方式
- 使用
## RED、## GREEN、## REFACTOR 三段汇报。
- 说明修改了哪些测试文件、哪些实现文件,以及运行了哪些测试命令。
- 最后补充剩余风险、未覆盖场景或后续建议。
使用示例
/tdd src/utils/format.ts - 为 format.ts 编写测试
/tdd add user validation - 实现用户验证功能 (TDD 方式)
/tdd - 为当前 git 变更编写测试