tdd

测试驱动开发

TDD 是红 → 绿循环。这项技能是该循环的参考指南，帮助你编写值得保留的测试：什么是好的测试、测试应放在哪里、反模式有哪些，以及循环的规则。每个部分在每个周期中都适用——请在循环开始前和进行中查阅，而不是事后再看。

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

什么是好的测试

测试通过公共接口验证行为，而非实现细节。代码可以彻底改变，测试则不应改变。好的测试读起来像一份规范——“用户可以使用有效购物车结账”能准确说明具备什么能力——而且由于不依赖内部结构，重构后仍然有效。

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

接缝——测试应放在哪里

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

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

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

当接口本身的形态尚未确定——例如模块的深度、接缝的位置、接口应公开什么——请使用 /codebase-design 技能中的术语。它是模块、接口、深度、接缝、适配器、杠杆和局部性等术语的共同来源，也是一份供查阅的参考资料，而不是需要执行的会话。

反模式

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

循环规则

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