tdd

name	tdd
description	测试驱动开发。适用于用户希望以测试优先方式构建功能或修复缺陷、提到“red-green-refactor”，或需要集成测试时。

测试驱动开发

TDD 是“红 → 绿”闭环。本 Skill 提供一套参考原则，使闭环产出值得长期保留的测试：什么是好测试、测试应放在哪里、需要避免哪些反模式，以及闭环本身必须遵守什么规则。每一轮都适用全部章节；应在闭环开始前和进行中查阅，不能等结束后再补看。

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

什么是好测试

测试应通过公共接口验证行为，不能验证实现细节。代码内部可以彻底改变，测试不应因此失效。好测试读起来像一条规格：“用户可以使用有效购物车完成结账”明确说明了系统具备什么能力。由于它不关心内部结构，重构后仍然成立。

示例参见 tests.md，Mock 指南参见 mocking.md。

Seams——测试应该放在哪里

Seam 是接受测试的公共边界：你可以在这个接口上观察行为，而无需伸入内部。测试只应位于 seams 上，绝不针对内部实现。

只在预先确认的 seams 上测试。 编写任何测试前，先列出准备测试的 seams，并与用户确认。未经确认的 seam 上不得编写测试。你不可能测试一切；提前商定 seams，才能把测试精力集中在关键路径和复杂逻辑上，避免把每个边缘情况都纳入测试。

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

反模式

• 与实现耦合（Implementation-coupled）——Mock 内部协作者、测试私有方法，或绕过接口通过旁路验证，例如直接查询数据库。判断信号：系统行为没有改变，仅仅重构就让测试失败。
• 同义反复（Tautological）——断言按照代码采用的同一种方法重新计算期望值，例如 expect(add(a, b)).toBe(a + b)、手工以相同算法生成快照，或断言一个常量等于自身。这类测试从构造上就必然通过，永远无法与代码产生分歧。期望值必须来自独立事实来源，例如已知正确的字面值、手工推导的示例或规格。
• 横向切片（Horizontal slicing）——先批量写完所有测试，再批量实现。批量测试验证的是想象中的行为：测试关注事物的形状，无法敏感反映真实行为变化，并且在尚未理解实现前就锁定测试结构。应改用纵向切片：一条测试 → 一段实现 → 重复。每条测试都是一枚示踪弹（tracer bullet），会根据上一轮得到的认识调整方向。

闭环规则

• 先红后绿。 先写失败测试，再只编写足以让它通过的代码。不要提前照顾未来测试，也不要加入推测性功能。
• 每轮只完成一个切片。 每轮只处理一个 seam、一条测试和一份最小实现。
• 重构不属于这个闭环。 重构应放到审查阶段完成，参见 code-review Skill；它不属于“红 → 绿”的实现循环。