测试驱动开发

TDD 是红 → 绿的循环。这个技能是让那个循环产出值得保留的测试的参考：什么是好测试、测试放在哪里、反模式，以及循环的规则。每一节在每个周期都适用——在循环之前和之中查阅它们，而不是之后。

在探索代码库时，读 CONTEXT.md（如果存在），让测试名和接口词汇与项目的领域语言相符，并尊重你正在触碰的区域里的 ADR。

什么是好测试

测试通过公共接口验证行为，而不是实现细节。代码可以整个改变；测试不该变。一个好测试读起来像一份规格说明——「用户可以用有效购物车结账」明确告诉你存在什么能力——而且它能在重构中存活，因为它不关心内部结构。

示例见 tests.md，mock 指南见 mocking.md。

接缝——测试放在哪里

一个接缝是你在其处测试的公共边界：你在这个接口上观察行为而不伸进内部。测试活在接缝处，绝不针对内部。

只在预先约定的接缝处测试。 在写任何测试之前，写下受测的接缝并与用户确认。在未确认的接缝处不写任何测试。你不可能测试一切——预先约定接缝，是让测试努力落在关键路径和复杂逻辑上、而不是落在每个边界情况上的办法。

问：「公共接口是什么，我们该在哪些接缝处测试？」

当那个接口的形状本身成问题时——模块该有多深、接缝该在哪里、接口该暴露什么——用 /codebase-design 技能获取词汇。它是模块、接口、深度、接缝、适配器、杠杆和局部性这些术语的共享来源，而且它是一份供查阅的参考，不是一个供运行的会话。

反模式

• 实现耦合 — mock 内部协作者、测试私有方法，或通过侧信道验证（查数据库而不是用接口）。破绽：当你重构时测试坏了，但行为并没变。
• 同义反复 — 断言以代码计算期望值的同样方式重新计算它（expect(add(a, b)).toBe(a + b)、一个用同样方式手工推导的快照、一个断言等于自身的常量），所以它天生就通过、永远不可能与代码相左。期望值必须来自一个独立的真理来源——一个已知良好的字面量、一个手算的例子、规格。
• 横向切片 — 先写所有测试，再写所有实现。批量测试验证的是想象的行为：你测的是事物的形状而非面向用户的行为，测试对真实改动变得不敏感，而且你在理解实现之前就绑死了测试结构。改为在纵向切片里工作——一个测试 → 一个实现 → 重复，每个测试都是一颗曳光弹，回应上一个周期教给你的东西。

循环的规则

• 先红后绿。 先写失败的测试，然后只写刚好足以让它通过的代码。不要预判未来的测试或添加投机性的功能。
• 一次一个切片。 每个周期一个接缝、一个测试、一个最小实现。
• 重构不是循环的一部分。 它属于审查阶段（见 code-review 技能），而不是红 → 绿的实现周期。