tdd

测试驱动开发

TDD 是 red → green 循环。本技能是这套循环的参考指南，旨在让你编写出值得长期维护的测试：什么是好的测试、测试应该放在哪里、有哪些反模式，以及循环规则。每个部分都适用于每一轮循环——请在循环开始前和进行中查阅，而不是结束后再看。

探索代码库时，请阅读 CONTEXT.md（如果存在），确保测试名称和界面术语符合项目的领域语言，并遵守你正在处理区域的 ADR。

什么是好的测试

测试应通过公共接口验证行为，而不是实现细节。代码可以彻底改变，测试却不应因此改变。好的测试读起来就像一份规范——“用户可以使用有效购物车结账”能明确说明存在什么能力——而且不会在重构后失效，因为它不依赖内部结构。

请参阅 tests.md 查看示例，并参阅 mocking.md 查看 mock 指南。

接缝——测试所在的位置

接缝是你进行测试的公共边界：在这里，你可以观察行为，而不必深入内部。测试应位于接缝处，绝不能针对内部实现。

只在预先商定的接缝处测试。 编写任何测试之前，先记录要测试的接缝，并与用户确认。未经确认，不得在某个接缝处编写测试。你无法测试所有内容——提前商定接缝，才能让测试工作聚焦于关键路径和复杂逻辑，而不是覆盖所有可能的边缘情况。

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

如果接口本身的形式尚未确定——模块应有多深、接缝在哪里、接口应暴露什么——请使用 /codebase-design 技能了解相关术语。该技能是模块、接口、深度、接缝、适配器、杠杆和局部性的共享术语来源，也是供你查阅的参考资料，而不是需要执行的流程。

反模式

• 与实现耦合——mock 内部协作者、测试私有方法，或通过旁路验证（例如查询数据库，而不是使用接口）。明显迹象是：重构后测试失败，但行为并未改变。
• 同义反复——断言以与代码相同的方式重新计算预期值（expect(add(a, b)).toBe(a + b)、通过相同路径手动推导出的快照，或断言常量等于自身），因此测试必然通过，永远无法发现代码有误。预期值必须来自独立的事实来源——已知正确的字面值、手工演算的示例或规范。
• 横向切片——先写完所有测试，再写完所有实现。一次性写出的测试验证的是_想象中的_行为：你测试的是事物的_形状_，而不是面向用户的行为；测试对实际变化不敏感；并且你会在了解实现之前就确定测试结构。请采用纵向切片——一次一个测试 → 一个实现 → 重复；每个测试都是一枚示踪弹，用于回应上一轮循环带来的认知。

循环规则

• 先 red，再 green。 先编写会失败的测试，然后只写足以让它通过的代码。不要提前编写未来的测试，也不要添加推测性功能。
• 一次一个切片。 每个循环只处理一个接缝、一个测试和一个最小实现。
• 重构不属于循环。 重构应放在审查阶段（参阅 code-review 技能），而不是 red → green 实现循环中。