whthomas
返回现场笔记
4 分钟阅读

单元测试里的 Dummy / Stub / Spy / Mock / Fake

从 Uncle Bob 的《The Little Mocker》到 Martin Fowler 的《Mocks Aren't Stubs》，梳理单元测试中 Dummy、Stub、Spy、Mock、Fake 五类测试对象的递进关系，以及经典模式与 mock 模式在设计哲学上的差异。

  • #unit-test
  • #testing
  • #methodology

一、争论的起点

晚上团队对于单元测试编写发生了不小的争论，在此之前我对单元测试的几种模式并不是特别清楚，晚上阅读了几篇文章，学习到了一些关于单元测试的概念。

讨论的起点源自一位同事分享的这篇大牛 Uncle Bob 的文章《The Little Mocker》。原来我没有特别认真地阅读这篇文章，一味倾向于使用 mock；而且在阅读 Bob 的《架构整洁之道》里，Bob 大叔提到"一切外部依赖都是可以模拟的"，晚上我仔细阅读一番才发现，这本书的翻译可能是有问题的——我原来以为中文里的"模拟"指的是单词 mock，实际上他指的应该是一类测试的对象。而在这篇文中，Bob 大叔主要是在分析这几种单测对象的区别。

争论的起点：两个对话气泡对峙，一本《The Little Mocker》落下成为催化剂， 随后浮现「模拟指的是测试替身，而不只是 mock」的领悟。

Debate · 争论的起点

一篇文章，把「模拟」两个字掰开了

单元测试怎么写?都用 mock 呀「模拟」≠ 只有 mock，它指的是这一类：测试替身
讨论从 Uncle Bob 的《The Little Mocker》开始——才意识到书里说的「模拟」是一类测试对象的总称，并不只等于 mock。

二、五类测试对象

单元测试将测试对象分为几类：

  1. Dummy Object：不参加测试的类的实现。
  2. Test Stub：一些需要固定返回值的类的实现。
  3. Test Spy：参与测试的类的实现，并且还要验证它的参与产生了某种结果。
  4. Mock Object：参与测试的类的实现，针对对象预先指定期望返回值，它关心的是什么函数被调用、调用了什么参数、什么时候和有多频繁被调用。
  5. Fake Object：一个假的真实业务实现，比如特定的入参可以返回 true，有点像是系统的后门。
五类测试替身的卡片画廊：Dummy、Stub、Spy、Mock、Fake，各自承担不同角色。

Test Doubles · 五类替身

同样是「替身」，干的事情完全不一样

Dummy01

傀儡对象

占位，不参与测试

Stub02

测试桩

按需返回固定值

Spy03

测试间谍

记录并验证结果

Mock04

模拟对象

预设期望，验证行为

Fake05

假实现

假的真实业务实现

从左到右，替身对测试的「介入程度」逐步加深——这也是下一节「递进关系」的伏笔。

以上的内容具体其实可以拜读一下《The Little Mocker》，译文在 antinomy.top · The Little Mocker 译文 ，文字很简单，但是内容非常丰富。

三、递进关系

通过比较可以看到，从 Dummy Object 到 Mock Object，测试代码的要求是越来越强的，这里有一个递进关系。

递进关系：从 Dummy 到 Mock 的四节阶梯，测试要求越来越强； Fake 作为另起一支的真实假实现，不在阶梯之上。

Progression · 递进关系

从 Dummy 到 Mock，要求一步步收紧

01020304DummyStubSpyMock要求越来越强Fake另起一支 · 真实假实现
Bob 大叔提倡在阶梯里挑「刚好够用」的那一级——减少强要求的替身，以减轻测试与实现的耦合。

所以 Bob 大叔提倡的是在递进关系中寻找合适的测试类型，减少强要求的测试对象，以减轻测试代码的耦合。当然这篇文章在 Reddit 里引发了非常多的讨论，讨论的内容也非常精彩：reddit.com · The Little Mocker 讨论

四、Mocks Aren't Stubs

后面在另外一位大牛 Martin Fowler 的博客里读到了《Mocks Aren't Stubs》这篇文章（文章是在 08 年写的，Martin Fowler 的预见性实在是太强了）。这篇文章主要是在讨论 Mocks 和 Stubs，他倒是没有对某一种测试对象有很强的倾向性，整篇文章都在不断分析和比较两种模式（打桩模式和 mock 模式）的区别。他认为这两种模式是在鼓励两种不同的设计风格，文中特别强调了两种模式的不同：

  • 测试结果的验证方式的不同：一个是状态验证（Stubs），另一个是行为验证（Mock），Mock 模式比较强调自外向内的测试。
  • 测试与设计哲学的完全不同：我将它们分别称之为，一个是传统型的，另一个是 mockist（mock 风格）的。
  • 基础设施的构建策略不同：Mock 模式是在避免复杂基础设施的构建，经典模式是寄希望于第一次构建的基础设施反复被复用。
  • 失败的影响范围不同：当使用经典测试时，任何使用了这个模块的测试都会失败，并且还会使得其他间接依赖的协作对象也失败。Mock 模式把主要对象外的其他依赖 mock 掉，这就使得协作对象能获得更好的粒度。经典测试会关注整个 case 的全景，而 mock 测试更加关注这一个小的单元。

在一些状态验证很难被使用的场景中，其实行为验证是非常必要的——比如文中提到的缓存是否命中，其实靠状态是没法验证的，只能通过 mock，关注对象的行为。

同一个被测对象向左右分叉：左侧状态验证看结果，右侧行为验证看调用序列。

Verification · 两种验证

分歧不在工具，而在「拿什么当证据」

被测对象 SUT状态验证State · Classical结果看结果对不对行为验证Behavior · Mockistsave()notify()看调用对不对
两种模式鼓励不同的设计风格——状态验证关注整个 case 的全景，行为验证更聚焦一个小单元，缓存命中这类场景尤其离不开它。

这篇文章的译文非常多，我选出自己感觉最佳的一篇译文：predatorray.me · Mock 并非 Stub（译文） 。个人认为这篇文章价值非常大，是高于 Bob 大叔那一篇的，非常推荐大家来阅读一下。

五、回到我们的场景

所以基于这样的分析，我觉得其实在我们的场景里大部分 Case 是可以采用经典模式处理，但是对于外部系统的调用应该采用一些 Mock。

系统边界图：内部业务模块以经典模式真实测试，外部的数据库、第三方 API、 消息队列裹上 mock 盾，调用止于盾上。

Boundary · 内外有别

内部走经典，外部套 Mock

我们的系统业务模块 A业务模块 B数据库mock第三方 APImock消息队列mock内部 · 经典外部 · Mock
边界之内，业务逻辑跑全套、状态自己验；边界之外，把不可控的依赖挡在 mock 盾后——单测就稳了，也轻了。

很长一段时间里，我认为单元测试是为了验证业务是否可用、避免上线前反复测试同样的 case。这段时间学习下来，发现单测的水很深——它本身是让我们在思考测试的编写中，逐步发现业务代码的编写构建问题，并找出我们系统的耦合点。

六、涉及的文章