关于 test-driven-development
test-driven-development 是一项面向开发者的测试驱动开发技能，指导按“先失败测试、再最简实现、最后重构”的循环推进代码变更。它强调围绕可观察行为设计测试，并在每次生产代码变更前验证需求。
主要功能
- 01红—绿—重构循环
- 02一次编写并完成一个测试
- 03按行为而非实现细节测试
- 04仅在输入输出边界使用模拟
- 05先让测试通过再重构
- 06用失败测试复现缺陷
适用场景
- 01为新功能按垂直切片编写测试
- 02在修复缺陷前复现问题
- 03通过测试设计接口
- 04重构时维持测试通过
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/test-driven-development确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/design-for-testability.mdmocking-boundaries.mdtest-quality.md详细介绍
测试驱动开发
编写一个描述下一项行为的失败测试，编写能通过该测试的最少代码，然后在测试保持通过的情况下重构。每项生产代码变更都从一个证明需求确实存在的测试开始。这是每个纵向切片中的实践准则——重点不在框架语法，而在于何时以及为何编写测试。
以下情况可以跳过：探索性原型开发、仅修改配置（环境变量、功能标志）、仅调整视觉效果或 CSS，以及不会持续维护的一次性脚本。
快速参考 — TDD 周期
| 阶段 | 操作 | 规则 |
|---|---|---|
| RED | 编写一个因正确原因而失败的测试 | 没有失败测试，就不写生产代码 |
| GREEN | 编写能让测试通过的最简单代码 | 抵制过早泛化的冲动 |
| REFACTOR | 在所有测试保持通过的情况下改进结构 | 绝不同时改变行为和结构 |
快速参考 — 原则
| 原则 | 实践 |
|---|---|
| 一次编写一个测试 | 完成整个 red-green-refactor 周期后，再编写下一个测试 |
| 行为优先于实现 | 测试代码的行为，而不是实现方式；断言输出和副作用 |
| 纵向切片 | 一次对一个端到端行为进行 TDD，而不是一次对一层进行 TDD |
| 在边界处使用模拟 | 模拟 I/O、网络、文件系统和时钟。绝不模拟内部协作者 |
| 深模块 | 设计简洁的接口和丰富的内部实现；用更少的测试覆盖更多行为 |
| 仅在测试通过时重构 | 修改结构前确保所有测试通过；在测试失败时重构会掩盖新错误 |
| 通过测试进行设计 | 第一个测试就是 API 设计决策；测试写起来别扭，说明接口也可能设计得别扭 |
| 每个缺陷都要有失败测试 | 编写修复代码前，先用失败测试复现缺陷 |
编码前规划
| 步骤 | 操作 | 输出 |
|---|---|---|
| 1 | 确定行为 | 功能必须展现的可观察行为列表 |
| 2 | 按依赖关系排序 | 每项测试都基于之前已通过测试构成的顺序 |
| 3 | 设计接口 | 函数签名、参数类型、返回类型 |
| 4 | 确定模拟边界 | 需要测试替身的外部依赖 |
常见错误
| 错误 | 正确做法 |
|---|---|
| 一次性编写所有测试 | 一次编写一个测试。完成整个循环后再开始下一个 |
| 测试私有方法 | 通过公共接口进行测试；私有方法属于实现细节 |
| 模拟内部协作者 | 仅在 I/O 边界进行模拟；信任自己的代码 |
| 在失败测试前编写代码 | 先 RED。失败的测试证明缺少相应行为 |
| 测试仍为红色时进行重构 | 先达到 GREEN，再有把握地进行重构 |
| 测试与调用顺序耦合 | 断言输出和状态，而不是断言调用了哪些内部方法 |
| 跳过重构阶段 | 达到 GREEN 还不算完成。继续之前，先清理重复代码并改进命名 |
| 对预期值进行硬编码 | 使用三角验证：添加第二个测试用例，迫使方案具有通用性 |
| 每个功能只编写一个大型测试 | 每种行为编写一个测试——小巧、聚焦且独立有意义 |
委派
- 切片分解：如果有
tracer-bullets技能，请使用它将功能分解为纵向切片，然后在每个切片中应用 TDD - 测试框架语法：将特定于框架的模式委派给
vitest-testing、e2e-testing或api-testing技能 - 功能规划：如果有
plan-first-development技能，请在进入 TDD 循环前使用它进行预先规划 - 单个 TDD 循环：将每个红—绿—重构循环委派给
Task子 Agent，以保持上下文聚焦
参考资料
评论
支持 Markdown