测试的四个阶段
- 初始化
- 执行测试
- 验证结果
- 复原
状态验证与行为验证
状态验证
简单的理解：一波操作后验证返回结果是否和预期一样
行为验证
- 简单理解：验证一波操作是否严格按预期的顺序执行，不管结果
- 对 TDD 用处不大
- 大多数情况下会丧失测试的有效性
Martin Folwer 《Mocks Aren’t Stubs》，对于不同的测试替身给予了充分的说明
TDD 中的单元测试
- 在 TDD 的语境下，“单元测试”指的是能提供快速反馈的低成本的研发测试（Developer Test）
- 将所有直接耦合都视为坏味道的设计取向，会将功能需求的上下文打散到一组细碎的对象群落中，增加理解的难度。最终滑向过度设计（Over Design）的深渊。
- 坏味道通常源自过高认知负载（Cognitive Load）或不易修改，俗称“看不懂改不动”。比如，坏味道过长的方法（Long Method）不是以绝对代码长度来衡量的，而是以“是否超出认知负载或难以改变其中的行为”来衡量的。而将功能上下文切得过于细碎，也会增加认知负载。因而不能单纯地认为，这种风格就一定是好的设计。
❗️ 原来如此
在测试驱动开发中，从来没有强调必须是“单元测试”。反而在大多数情况下，都是针对不同单元粒度的功能测试。并通过这一系列不同单元粒度的功能测试，驱动软件的开发
两位超级大佬说的
- 通过构造恰当粒度的黑盒功能测试驱动开发（—— Kent Beck）
- TDD 社区所谓的单元测试到底是：能提供快速反馈的低成本的研发测试（—— Martin Folwer）
- 原文： UnitTest
- Martin Fowler 还建议将 TDD 中的测试叫作极限单元测试（Xunit Testing），以区别于行业中的叫法