tdd

TDD — 测试驱动开发

测试驱动开发。用户想要先编写测试再构建功能或修复 bug、提到“红—绿—重构”，或想要集成测试时使用。

此技能从 mattpocock/skills（MIT）导入，上游由模型调用。

何时使用此技能

• 测试驱动开发。
• 用户想要先编写测试再构建功能或修复 bug、提到“红—绿—重构”，或想要集成测试时使用。

说明

测试驱动开发

TDD 是红 → 绿循环。此技能是参考指南，旨在让循环产出值得保留的测试：什么是好的测试、测试应放在哪里、反模式，以及循环的规则。每个循环的每个阶段都适用所有章节：在循环之前和过程中查阅，而不是之后。

探索代码库时，阅读 CONTEXT.md（如果存在），确保测试名称和接口术语符合项目的领域语言，并遵循所涉及区域的 ADR。

什么是好的测试

测试通过公共接口验证行为，而不是实现细节。代码可以完全改变，测试不应因此改变。好的测试读起来像一份规范：“用户可以使用有效购物车结账”能准确说明存在什么能力，而且不会受重构影响，因为它不关心内部结构。

示例请参阅 tests.md，模拟指南请参阅 mocking.md。

接缝：测试应放在哪里

接缝是你要测试的公共边界：无需深入内部即可观察行为的接口。测试应位于接缝处，而不是针对内部实现。

只在事先约定的接缝处测试。 编写任何测试之前，先写下要测试的接缝，并与用户确认。未经确认的接缝处不得编写测试。你无法测试所有内容，因此事先约定接缝，才能让测试投入聚焦于关键路径和复杂逻辑，而不是每种边缘情况。

提问：“公共接口是什么？我们应该测试哪些接缝？”

如果接口本身的形态仍有疑问（模块的深度、接缝的位置、接口应公开什么），请调用 Skill 工具并输入“codebase-design”以获取相关术语。它是模块、接口、深度、接缝、适配器、杠杆和局部性这些术语的共享来源，可供查阅参考，而不是要运行的会话。

反模式

• 与实现耦合：模拟内部协作者、测试私有方法，或通过旁路验证（例如查询数据库而不是使用接口）。其特征是：重构后测试会失败，但行为并未改变。
• 同义反复：断言以与代码相同的方式重新计算预期值（expect(add(a, b)).toBe(a + b)、以相同方式手动生成的快照、断言常量等于自身），因此测试必然通过，永远无法与代码结果不一致。预期值必须来自独立的事实来源：已知正确的字面值、完整示例或规范。
• 横向切分：先编写所有测试，再编写所有实现。批量测试验证的是_想象中的_行为：测试的是事物的_形态_，而不是面向用户的行为；测试会对实际变更失去敏感度；并且你会在理解实现之前就定下测试结构。应改为按纵向切片开展工作：一次编写一个测试、实现一次，然后重复；每个测试都是一颗曳光弹，根据上一轮的经验作出调整。

循环规则

• 先红后绿。 先编写会失败的测试，然后只写足以让它通过的代码。不要预判未来的测试，也不要添加推测性功能。
• 一次一个切片。 每个循环只涉及一个接缝、一个测试和一个最小化实现。
• 重构不属于循环。 重构属于评审阶段（请参阅 code-review 技能），而不是红 → 绿实现循环的一部分。

示例

• 先将此技能应用于一个狭窄范围，确认输出符合上述格式，然后再扩展到整个任务。
• 如果某个步骤需要从代码仓库或环境中获取事实，就自行查找，而不是向用户询问。

最佳实践

• 保持上游流程不变；如有偏差，应明确记录，而不是默默自行变通。
• 每当此技能标记某个决策点由用户决定时，就停止并将控制权交还给用户。
• 优先进行小幅、可撤销的更改，并说明假设，而不是将其隐藏起来。

参考资料

• 上游技能：mattpocock/skills skills/engineering/tdd/SKILL.md（提交 3cca18b，MIT）
• 配套文档：references/mocking.md
• 配套文档：references/tests.md
• 项目规范：.agent-skills/skill-standardization/SKILL.md
• 验证脚本：.agent-skills/skill-standardization/scripts/validate_skill.sh