tdd

tdd

与其给出冗长的规格说明，Agent 在紧密的反馈循环中编码效果更好。失败的测试就是最紧密的反馈循环：它明确了目标，而目标要么通过，要么不通过。

循环

1. 红。 编写一个失败的测试，描述下一小步行为。运行它。确认失败原因正确——如果在你编写代码前测试就通过了，那它什么也没测到。如果测试不是断言失败，而是直接报错，先修复测试设置。
2. 绿。 编写能让测试通过的最少代码。不是通用解决方案，也不是抽象，只做最小改动。运行测试。通过。
3. 重构。 现在以测试为安全网进行清理：消除重复、为内容命名、简化代码。每次修改后都重新运行测试。行为已冻结；只改变代码的结构。
4. 针对下一小步重复以上过程。每步都要小。反馈速度就是速度上限——绝不要选择大到无法用单个测试验证的步骤。

什么样的测试值得编写

• 测试行为，而非实现。 断言可观察到的结果，而不是调用了哪个私有方法。每次重构都会导致测试失败的测试是负担。
• 每个测试只因一个原因失败。 每个测试锁定一种行为。测试变红时，你应该不用阅读测试内容就知道出了什么问题。
• 使用真实边界，尽量少用模拟。 在系统边界（网络、时钟、文件系统）使用模拟，而不是模拟内部协作者。模拟被测对象的测试什么也没验证。
• 不要写同义反复的测试。 重述实现的测试（例如，设置 x 后执行 expect(x).toBe(x)）什么也验证不了。应断言该行为应产生的值。

何时使用

当行为可以明确描述，并且可以用测试锁定时，使用 TDD：业务逻辑、解析器、状态机、错误修复（先编写失败用例，再修复）。对于纯探索、一次性试验，以及测试无法断言任何人眼无法直接判断的纯布局 UI，则跳过 TDD。

输出约定

展示每次从红到绿的转换，而不只是最终通过的结果。如果测试很难编写，请说明这种困难揭示了设计的哪些问题——无法测试的代码通常是边界划分不当的代码；这是一个发现，而非障碍。