tdd

测试驱动开发

TDD 即红 → 绿循环。本 Skill 是让该循环产出值得保留的测试的参考：什么是好测试、测试放在哪里、反模式以及循环规则。每一节都适用于每个循环：在循环前后和循环过程中查阅，而不是事后再看。

探索代码库时，若存在 GLOSSARY.md，请先阅读它，使测试名称和接口用词与项目的领域语言保持一致，并遵守你所修改区域中的 ADR。

什么是好测试

测试通过公共接口验证行为，而不是实现细节。代码可以彻底改变，测试不应随之改变。好测试读起来像一份规格说明：「用户可以用有效购物车完成结账」准确说明了存在哪种能力，并且在重构后依然成立，因为它不关心内部结构。

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

接缝：测试放在哪里

接缝（seam）是你进行测试所依托的公共边界：无需深入内部即可观察行为的接口。测试位于接缝处，绝不针对内部实现。

只在预先约定的接缝上测试。 在编写任何测试之前，先写下待测的接缝，并与用户确认。未经确认的接缝上不编写测试。你无法测试所有内容，预先约定接缝可以确保测试精力集中在关键路径和复杂逻辑上，而不是覆盖每一个边界情况。

请询问：「公共接口是什么，我们应该测试哪些接缝？」并为每个提议的接缝附上一行说明，写明它能捕获什么、遗漏什么。

当该接口本身的形态存在疑问时（模块有多深、接缝应放在哪里、接口应暴露什么），请使用 "codebase-design" 调用 Skill 工具以获取相关术语。它是模块、接口、深度、接缝、适配器、杠杆率和局部性等术语的共享来源，是供查阅的参考，而不是需要运行的会话。

反模式

• 与实现耦合：mock 内部协作对象、测试私有方法，或通过旁路验证（直接查询数据库，而不是使用接口）。典型表现：重构时测试失败，但行为并未改变。
• 同义反复：断言以与代码相同的方式重新计算期望值（expect(add(a, b)).toBe(a + b)、以相同方式手工推导的快照、或将常量与自身比较），因此它必然通过，永远不会与代码产生分歧。期望值必须来自独立的事实来源：已知正确的字面量、一个算好的示例，或规格说明。
• 水平切片：先写完所有测试，再写所有实现。批量测试验证的是想象中的行为：你测试的是事物的形态，而非面向用户的行为；这些测试会对真实变化变得不敏感，并且在理解实现之前就锁定了测试结构。应改为以垂直切片方式工作：一个测试 → 一个实现 → 重复，每个测试都是一颗示踪弹（tracer bullet），并根据上一轮循环所学来调整。

循环规则

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