test-driven-development · 测试驱动开发
写功能或修 bug 前，先写测试：看它失败，再写最少代码让它通过，然后重构。
铁律：没有先失败的测试，就没有生产代码——先写代码再补测试的，删掉重来。红（写失败测试）→ 验证红（确认失败原因正确）→ 绿（最小实现）→ 验证绿（全套件通过）→ 重构。例外（抛原型、生成代码、配置文件）需先问过人类伙伴。
调用示例：在聊天框中说"用 TDD 给我实现这个重试逻辑"。
产品详解
定位
test-driven-development 是一套严格的开发纪律：先写测试，看它失败，再写最小代码让它通过。它管的是"写代码的顺序"，不是测试写法教程。
核心能力
- 铁律：没有先失败的测试就不写生产代码；先写了代码的，删掉重来。
- 红-绿-重构循环：红（写失败测试）→ 验证红（确认失败原因是功能缺失而非笔误）→ 绿（最小实现）→ 验证绿（当前测试 + 全项目套件通过）→ 重构（保持绿色）。
- 好测试标准：一行为一测（名字里出现"和"就拆）、名字描述行为、测真实代码而非 mock。
- 最小实现：只写让测试通过的代码，不加特性、不重构其他代码、不"顺手优化"。
- bug 修复：先写复现 bug 的失败测试，再按 TDD 循环修复，测试即回归保障。
- 常见借口驳回："太简单不用测""事后补测也一样""手动测过就行""删掉重写是浪费"——全部驳回并给出理由。
- 红线清单：代码在测试前、测试立即通过、说不清测试为什么失败、测试"以后再加"、"这次例外"——出现任何一条就删掉重来。
工作流程
- 写一个最小测试，描述期望行为
- 运行，确认失败（失败而非报错，失败原因符合预期）
- 写最小代码让测试通过
- 运行当前测试 + 项目全套件，确认全绿且输出干净
- 重构（去重、改名、抽取），保持绿色
- 下一个测试，重复循环
输入与输出
| 输入 | 必填 | 说明 |
|---|---|---|
| 功能需求/bug | 是 | 要实现的功能或要修复的 bug |
输出：有测试先行的代码 + 全绿的测试套件。
适用场景
- 新功能实现
- bug 修复
- 重构
- 行为变更
使用前准备
- 无需 API key；需要项目有可运行的测试框架。
- 例外需人类伙伴批准：抛原型、生成代码、配置文件。
- 验收清单：每个新函数都有测试；看过每个测试失败；失败原因符合预期；实现最小；全套件通过；输出干净。
test-driven-development 隶属于 Aiglade Skill 库。在 Aiglade 聊天框中用自然语言描述需求即可调用。