测试驱动开发（Test-Driven Development）

TDD 是红 → 绿循环（red → green loop）。本技能提供让该循环产出值得保留的测试所需的规范：什么是良好测试、测试应放在哪里、反模式（anti-patterns）以及循环规则。每一节都适用于每一轮循环：要在循环开始前和进行中查阅，而不是事后查阅。

探索代码库时，读取 GLOSSARY.md（如果存在），使测试名称和接口词汇符合项目的领域语言，并遵守所涉及区域的 ADR。

什么是良好测试

测试应当通过公共接口（public interfaces）验证行为，而不是验证实现细节。代码可以彻底改变，测试不应随之失效。良好测试读起来像规格：“用户可以使用有效购物车结账”明确说明了存在什么能力：并且因为不关心内部结构而能经受重构（refactors）。

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

接缝：测试应放在哪里

**接缝（seam）**是进行测试的公共边界：在这个接口上，无需进入内部就能观察行为。测试位于接缝处，绝不针对内部实现。

**只在预先约定的接缝处测试。**编写任何测试之前，先写下要测试的接缝并让用户确认。不要在未经确认的接缝处编写测试。你无法测试一切：预先约定接缝，才能把测试精力投入关键路径和复杂逻辑，而不是每个边缘情形。

询问：“公共接口是什么，我们应当测试哪些接缝？”为每个提议的接缝附上一行说明，指出它能发现什么、会遗漏什么。

当该接口本身的形态需要设计时（模块有多深、接缝应放在哪里、接口应暴露什么），调用 Skill 工具加载“codebase-design”，查阅共享词汇。它是模块、接口、深度、接缝、适配器、杠杆效应和局部性这些术语的统一来源；它是供查阅的参考，而不是需要运行的会话。

反模式

• 与实现耦合（implementation-coupled）：模拟内部协作者、测试私有方法，或者通过旁路验证（例如绕过接口直接查询数据库）。识别信号是：行为没有改变，测试却会因重构而失败。
• 同义反复（tautological）：断言用与代码相同的方式重新计算期望值（expect(add(a, b)).toBe(a + b)、以同样方式手工推导的快照、断言常量等于自身），因此它必然通过，永远不可能与代码产生分歧。期望值必须来自独立的事实来源：已知正确的字面值、完整演算的示例或规格。
• 水平切片（horizontal slicing）：先写完所有测试，再写完所有实现。批量测试验证的是_想象中的_行为：测试的是事物的_形状_而非面向用户的行为；测试无法感知真实变化；而且你在理解实现之前就承诺了测试结构。应当改用垂直切片（vertical slices）：一个测试 → 一个实现 → 重复；每个测试都是一枚曳光弹（tracer bullet），根据上一轮循环获得的认知作出响应。

循环规则

• **先红后绿。**先编写失败测试，再只写足以使其通过的代码。不要预判未来的测试，也不要添加推测性功能。
• **每次一个切片。**每轮循环只包含一个接缝、一个测试和一个最小实现。
• **重构不属于该循环。**它属于审查阶段（参见 code-review 技能），不属于红 → 绿实现循环。