tdd

name	tdd
description	"测试驱动开发。适用于需要以测试先行方式构建功能或修复 bug、提及"红-绿-重构"循环、或需要集成测试的场景。"

测试驱动开发

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

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

什么是好的测试

测试通过公共接口验证行为，而不是实现细节。代码可以完全改变；测试不应该。一个好的测试读起来像规范 —— "用户可以使用有效购物车结账" 准确地告诉你存在什么能力 —— 并且在重构后能够存活，因为它不关心内部结构。

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

接缝 —— 测试放置的位置

接缝（seam） 是你进行测试的公共边界：你在该接口处观察行为而不触及内部。测试位于接缝处，绝不针对内部细节。

仅在预先约定的接缝处进行测试。 在编写任何测试之前，写下要测试的接缝并与用户确认。没有在未确认的接缝处编写测试。你无法测试一切 —— 提前约定接缝可以确保测试工作集中在关键路径和复杂逻辑上，而不是每个边缘情况。

问："公共接口是什么，我们应该在哪些接缝处进行测试？"

反模式

• 与实现耦合 —— mock 内部协作者、测试私有方法、或通过旁路通道验证（查询数据库而不是使用接口）。特征：当重构时代码行为未变但测试却失败了。
• 同义反复 —— 断言以与代码相同的方式重新计算预期值（expect(add(a, b)).toBe(a + b)、以相同方式手动推导的快照、将常量断言为等于自身），因此它在构造上就必然通过，永远不可能与代码产生分歧。预期值必须来自独立的真相来源 —— 已知正确的字面量、手工计算示例、规范。
• 水平切片 —— 先写所有测试，再写所有实现。批量测试验证的是想象中的行为：你测试的是事物的形态而非面向用户的行为，测试变得对真实变更不敏感，并且你在理解实现之前就锁定了测试结构。应采用垂直切片 —— 一个测试 → 一个实现 → 重复，每个测试都是一颗曳光弹，响应上一个循环的反馈。

循环的规则

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