tdd

随 mattpocock/skills 中的 skills/engineering/tdd/SKILL.md 一起打包，版本为 4ae2317，采用 MIT 许可（LICENSE）。下方上游文本未经改动；末尾的 workflow-axa 适配内容会在与上游文本冲突时覆盖上游文本。

测试驱动开发

TDD 是红 → 绿循环。本技能是该循环的参考指南，旨在让循环产出值得保留的测试：什么是好的测试、测试应该放在哪里、反模式有哪些，以及循环的规则。每个部分都适用于每一轮：在循环开始前和进行期间查阅，而不是结束后再看。

探索代码库时，请阅读 GLOSSARY.md（如果存在），确保测试名称和接口术语符合项目的领域语言，并遵守你正在修改的区域中的 ADR。

什么是好的测试

测试通过公共接口验证行为，而非实现细节。代码可以彻底改变，测试不应如此。好的测试读起来就像一份规范：“用户可以使用有效购物车结账”明确说明了现有功能，而且不受重构影响，因为它不关心内部结构。

示例见 tests.md，模拟指南见 mocking.md。

接缝：测试位置

接缝是你进行测试的公共边界：你可以在不深入内部的情况下观察行为的接口。测试应位于接缝处，而非针对内部实现。

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

请询问：“公共接口是什么？我们应该测试哪些接缝？” 为每个提议的接缝写一句说明，指出它能捕获什么、遗漏什么。

当接口的形态本身存在疑问时（例如模块的深度、接缝的位置、接口应该暴露什么），请调用 Skill 工具并使用“codebase-design”来了解相关术语。它是模块、接口、深度、接缝、适配器、杠杆和局部性这些术语的共同参考来源，应作为参考查阅，而不是启动一个会话。

反模式

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

循环规则

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

---

workflow-axa 适配

• 接缝已达成一致。 workflow-specify 会记录每个工单的测试接缝，并在第二个关卡获得批准。请使用这些接缝；只有确实需要新增接缝时才询问。
• 术语。 如果项目中存在 CONTEXT.md（或 GLOSSARY.md）和 ADR，请阅读。
• 参考资料。 如果本文要求调用 Skill 工具并使用 codebase-design 或 code-review，请改为阅读 ../codebase-design/SKILL.md 或 ../code-review/SKILL.md（本软件包中的副本）。
• 如实说明。 缺少测试基础设施属于阻碍：切勿安装测试运行器、弱化测试，或声称进行了实际上并未发生的红绿循环。文档或配置工单则检查其声明的契约。