Test-Driven Development

Test-Driven Development 是什么

这是一个严格执行测试驱动开发的工程 Skill。它先让用户和代理对可观察行为与公共接口达成一致，再通过 Red–Green 循环逐个交付垂直切片，避免测试追着内部实现跑。

Red–Green 小步循环

每次先写一个能表达下一项行为的失败测试，确认它确实因缺少该行为而失败；随后只写让该测试通过的最小实现。通过后再选择下一项行为，不能一次预写整批测试，也不能顺手加入尚未需要的功能。

公共接口与预期值

测试应从公共 API、页面或命令等真实入口观察结果。预期值要独立计算，不能复制实现逻辑，否则实现与测试可能一起犯错。缺陷修复则先建立能稳定复现问题的测试，再做最小修复。

Mock、依赖与限制

Mock 只适合外部 API、时间、随机数、文件系统或部分数据库等系统边界，不应替代内部类或模块。测试仍依赖项目已有的测试框架和可运行环境。该 Skill 把重构留到 review 阶段，因此不是完整的设计或性能优化流程。

落地与验收

开始前要确认测试命令、目标公共入口和成功标准。每个循环都应保存失败证据，再保存通过结果，避免出现测试从未真正失败的假阳性。异步、时间和随机行为需要可重复控制；外部服务故障应在边界上模拟。完成一轮功能后还要运行相关测试集和静态检查，确认新行为没有破坏既有契约。

来源与许可

本条目依据 mattpocock/skills 固定提交中的完整 TDD 规则、测试与 mocking 参考整理，仓库声明 MIT 许可证。

常见问题

1. 核心循环是什么？

先写一个失败测试，再写最小实现让它通过，然后进入下一项可观察行为。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

2. 何时开始写测试？

先和用户确认公共接口及行为契约，避免测试建立在未确认的 API 上。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

3. 可以一次写完全部测试吗？

不建议。规则要求一个行为一个循环，保持失败原因清晰。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

4. 测试应该覆盖什么？

覆盖用户能观察到的行为、边界条件和错误结果，而不是私有方法调用次数。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

5. 何时可以使用 mock？

在外部服务、时间、随机性等难以稳定控制的系统边界使用。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

6. 数据库一定要 mock 吗？

不一定。可根据速度、隔离性和真实度选择临时数据库、容器或边界 mock。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

7. 重构在哪一步？

该工作流把重构留到 review 阶段，先保证行为测试和最小实现完整。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。

8. 适合修复缺陷吗？

适合。先写复现缺陷的失败测试，再修复并保留测试防止回归。实际使用时还应结合当前版本、权限、输入数据和运行环境复核结果，并在重要任务中保留人工确认。