tdd

测试驱动开发

TDD 是 red → green 循环。本技能是参考指南，帮助这个循环产出值得保留的测试：好测试是什么、测试应该放在哪里、反模式，以及循环的规则。每个部分都适用于每一轮循环：在循环前和循环过程中查阅，而不是结束后再看。

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

什么是好测试

测试通过公共接口验证行为，而不是实现细节。代码可以完全改变，测试则不应受影响。好测试读起来就像一份规范：“用户可以使用有效购物车结账”准确说明了系统具备什么能力，而且由于不依赖内部结构，即使重构也能通过。

接缝：测试放在哪里

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

只在事先约定的接缝处测试。 不得在未经确认的接缝处编写测试。你无法测试所有内容，因此事先约定接缝，才能让测试工作聚焦于关键路径和复杂逻辑，而不是每一个边界情况。

接缝可能已经约定。按以下顺序，采用第一个存在的信息源：

1. 工单中的 Seams: 行（或远程工单中的 Seams 部分）。
2. 规范中的 Testing Decisions。
3. 无。

信息源中的接缝视为已确认：可直接在这些位置编写测试，无需询问。只有接缝不在列表中时才询问用户，并在双方达成一致后将其加入列表。

如果没有信息源（独立使用，没有工单或规范），请列出要测试的接缝，并在编写任何测试之前与用户确认。询问：“公共接口是什么？我们应该测试哪些接缝？” 为每个提议的接缝写一行说明，指出它能捕获什么、无法捕获什么。

如果接口本身的形态尚未确定，例如模块应有多深、接缝应位于何处、接口应暴露什么内容：先解决这些问题，再约定接缝。

反模式

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

循环规则

• 先红后绿。 先编写失败的测试，然后只写足以让它通过的代码。不要预想未来的测试，也不要添加推测性功能。
• 一次一个切片。 每轮循环只涉及一个接缝、一个测试和一个最小实现。
• 重构不属于循环的一部分。 重构属于 implement 技能的 Refactor 步骤，而不是 red → green 实现循环。