Golang 单元测试详尽指引

文末有彩蛋。

作者：yukkizhang，腾讯 CSIG 专项技术测试工程师

本篇文章站在测试的角度，旨在给行业平台乃至其他团队的开发同学，进行一定程度的单元测试指引，让其能够快速的明确单元测试的方式方法。 本文主要从单元测试出发，对Golang的单元测试框架、Stub/Mock框架进行简单的介绍和选型推荐，列举出几种针对于Mock场景的最佳实践，并以具体代码示例进行说明。

一、单元测试

1. 单元测试是什么

单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类、超类、抽象类等中的方法。单元测试就是软件开发中对最小单位进行正确性检验的测试工作。

不同地方对单元测试有的定义可能会有所不同，但有一些基本共识：

单元测试是比较底层的，关注代码的局部而不是整体。

单元测试是开发人员在写代码时候写的。

单元测试需要比其他测试运行得快。

2. 单元测试的意义

提高代码质量。代码测试都是为了帮助开发人员发现问题从而解决问题，提高代码质量。

尽早发现问题。问题越早发现，解决的难度和成本就越低。

保证重构正确性。随着功能的增加，重构（修改老代码）几乎是无法避免的。很多时候我们不敢重构的原因，就是担心其它模块因为依赖它而不工作。有了单元测试，只要在改完代码后运行一下单测就知道改动对整个系统的影响了，从而可以让我们放心的重构代码。

简化调试过程。单元测试让我们可以轻松地知道是哪一部分代码出了问题。

简化集成过程。由于各个单元已经被测试，在集成过程中进行的后续测试会更加容易。

优化代码设计。编写测试用例会迫使开发人员仔细思考代码的设计和必须完成的工作，有利于开发人员加深对代码功能的理解，从而形成更合理的设计和结构。

单元测试是最好的文档。单元测试覆盖了接口的所有使用方法，是最好的示例代码。而真正的文档包括注释很有可能和代码不同步，并且看不懂。

3. 单元测试用例编写的原则3.1 理论原则

快。单元测试是回归测试，可以在开发过程的任何时候运行，因此运行速度必须快

一致性。代码没有改变的情况下，每次运行得结果应该保持确定且一致

原子性。结果只有两种情况：Pass / Fail

用例独立。执行顺序不影响；用例间没有状态共享或者依赖关系；用例没有副作用（执行前后环境状态一致）

单一职责。一个用例只负责一个场景

隔离。功能可能依赖于数据库、web 访问、环境变量、系统时间等；一个单元可能依赖于另一部分代码，用例应该解除这些依赖

可读性。用例的名称、变量名等应该具有可读性，直接表现出该测试的目标

自动化。单元测试需要全自动执行。测试程序不应该有用户输入；测试结果应该能直接被电脑获取，不应该由人来判断。

3.2 规约原则

在实际编写代码过程中，不同的团队会有不同团队的风格，只要团队内部保持有一定的规约即可，比如：

单元测试文件名必须以 xxx_test.go 命名

方法必须是 TestXxx 开头，建议风格保持一致（驼峰或者下划线）

方法参数必须 t *testing.T

测试文件和被测试文件必须在一个包中

3.3 衡量原则

单元测试是要写额外的代码的，这对开发同学的也是一个不小的工作负担，在一些项目中，我们合理的评估单元测试的编写，我认为我们不能走极端，当然理论上来说全写肯定时好的，但是从成本，效率上来说我们必须做出权衡，衡量原则如下：

优先编写核心组件和逻辑模块的测试用例

逻辑类似的组件如果存在多个，优先编写其中一种逻辑组件的测试用例

发现 Bug 时一定先编写测试用例进行 Debug

关键 util 工具类要编写测试用例，这些 util 工具适用的很频繁，所以这个原则也叫做热点原则，和第 1 点相呼应。

测试用户应该独立，一个文件对应一个，而且不同的测试用例之间不要互相依赖。

测试用例的保持更新

4. 单元测试用例设计方法4.1 规范(规格)导出法

规范(规格)导出法将需求”翻译“成测试用例。

例如，一个函数的设计需求如下：

函数：一个计算平方根的函数输入：实数输出：实数要求：当输入一个 0 或者比 0 大的实数时，返回其正的平方根；当输入一个小于 0 的实数时，显示错误信息“平方根非法—输入之小于 0”，并返回 0；库函数可以用来输出错误信息。

在这个规范中有 3 个陈述，可以用两个测试用例来对应:

测试用例 1：输入 4，输出 2。

测试用例 2：输入-1，输出 0。

4.2 等价类划分法

等价类划分法假定某一特定的等价类中的所有值对于测试目的来说是等价的，所以在每个等价类中找一个之作为测试用例。

按照 [输入条件][有效等价类][无效等价类] 建立等价类表，列出所有划分出的等价类

为每一个等价类规定一个唯一的编号

设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类。重复这一步，直到所有的有效等价类都被覆盖为止

设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类。重复这一步，直到所有的无效等价类都被覆盖为止

例如，注册邮箱时要求用 6~18 个字符，可使用字母、数字、下划线，需以字母开头。

测试用例：

4.3 边界值分析法

边界值分析法使用与等价类测试方法相同的等价类划分，只是边界值分析假定错误更多地存在于两个划分的边界上。

边界值测试在软件变得复杂的时候也会变得不实用。边界值测试对于非向量类型的值(如枚举类型的值)也没有意义。

例如，和4.1相同的需求：划分(ii)的边界为 0 和最大正实数；划分(i)的边界为最小负实数和 0。由此得到以下测试用例：

输入

输入

输入 0

输入

输入

4.4 基本路径测试法

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

基本路径测试法的基本步骤：

程序的控制流图：描述程序控制流的一种图示方法。

程序圈复杂度：McCabe 复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。

导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。

准备测试用例：确保基本路径集中的每一条路径的执行。

二、Golang 的测试框架

Golang 有这几种比较常见的测试框架：

从测试用例编写的简易难度上来说：testify 比 GoConvey 简单；GoConvey 比 Go 自带的 testing 包简单。　　但在测试框架的选择上，我们更推荐 GoConvey。因为：

GoConvey 和其他 Stub/Mock 框架的兼容性相比 Testify 更好。

Testify 自带 Mock 框架，但是用这个框架 Mock 类需要自己写。像这样重复有规律的部分在 GoMock 中是一键自动生成的。

1. Go 自带的 testing 包

为 Go 语言 package 提供自动化测试的支持。通过 命令，能够自动执行如下形式的任何函数：

注意： 可以是任何字母数字字符串，但是第一个字母不能是小写字母。

在这些函数中，使用 、 或相关方法来发出失败信号。

要编写一个新的测试套件，需要创建一个名称以 _test.go 结尾的文件，该文件包含 函数，如上所述。将该文件放在与被测试文件相同的包中。该文件将被排除在正常的程序包之外，但在运行 命令时将被包含。有关详细信息，请运行 和 了解。

1.1 第一个例子

被测代码：

测试代码：

执行 ，输出：

表示测试通过。我们将 函数改为：

再执行 ，输出：

1.2 Table-Driven 测试

Table-Driven 的方式将多个 case 在同一个测试函数中测到：

2. GoConvey：简单断言

Convey 适用于书写单元测试用例，并且可以兼容到 testing 框架中，命令或者使用命令访问的 Web 测试界面都可以查看测试结果。

一般 Convey 用来进行断言，断言的方式可以传入一个函数，或者使用自带的、、函数等。

2.1. 基本用法

被测代码：

测试代码

2.2. 双层嵌套

内层的 Convey 不需要再传入 t *testing.T 参数

3. testify

testify 提供了 assert 和 require，让你可以简洁地写出

3.1. assert

3.2. require

require 和 assert 失败、成功条件完全一致，区别在于 assert 只是返回布尔值（true、false），而 require 不符合断言时，会中断当前运行

3.3. 常用的函数

三、Stub/Mock 框架

Golang 有以下 Stub/Mock 框架：

GoStub

GoMock

Monkey

一般来说，GoConvey 可以和 GoStub、GoMock、Monkey 中的一个或多个搭配使用。

Testify 本身有自己的 Mock 框架，可以用自己的也可以和这里列出来的 Stub/Mock 框架搭配使用。

1. GoStub

GoStub 框架的使用场景很多，依次为：

基本场景：为一个全局变量打桩

基本场景：为一个函数打桩

基本场景：为一个过程打桩

复合场景：由任意相同或不同的基本场景组合而成

1.1. 为一个全局变量打桩

假设 num 为被测函数中使用的一个全局整型变量，当前测试用例中假定 num 的值大于 100，比如为 150，则打桩的代码如下：

stubs 是 GoStub 框架的函数接口 Stub 返回的对象，该对象有 Reset 操作，即将全局变量的值恢复为原值。

1.2. 为一个函数打桩

假设我们产品的既有代码中有下面的函数定义：

我们可以对 Exec 函数打桩，代码如下所示：

1.3. 为一个过程打桩

当一个函数没有返回值时，该函数我们一般称为过程。很多时候，我们将资源清理类函数定义为过程。

我们对过程 DestroyResource 的打桩代码为：

2. GoMock

GoMock 是由 Golang 官方开发维护的测试框架，实现了较为完整的基于 interface 的 Mock 功能，能够与 Golang 内置的 testing 包良好集成，也能用于其它的测试环境中。GoMock 测试框架包含了 GoMock 包和 mockgen 工具两部分，其中 GoMock 包完成对桩对象生命周期的管理，mockgen 工具用来生成 interface 对应的 Mock 类源文件。

2.1. 定义一个接口

我们先定义一个打算 mock 的接口 Repository。

Repository 是领域驱动设计中战术设计的一个元素，用来存储领域对象，一般将对象持久化在数据库中，比如 Aerospike，Redis 或 Etcd 等。对于领域层来说，只知道对象在 Repository 中维护，并不 care 对象到底在哪持久化，这是基础设施层的职责。微服务在启动时，根据部署参数实例化 Repository 接口，比如 AerospikeRepository，RedisRepository 或 EtcdRepository。

2.2. 生成 mock 类文件

这下该 mockgen 工具登场了。mockgen 有两种操作模式：源文件和反射。

源文件模式通过一个包含 interface 定义的文件生成 mock 类文件，它通过 -source 标识生效，-imports 和 -aux_files 标识在这种模式下也是有用的。举例：

反射模式通过构建一个程序用反射理解接口生成一个 mock 类文件，它通过两个非标志参数生效：导入路径和用逗号分隔的符号列表（多个 interface）。举例：

生成的 mock_repository.go 文件：

2.3. 使用 mock 对象进行打桩测试2.3.1. 导入 mock 相关的包

2.3.2. mock 控制器

mock 控制器通过 NewController 接口生成，是 mock 生态系统的顶层控制，它定义了 mock 对象的作用域和生命周期，以及它们的期望。多个协程同时调用控制器的方法是安全的。当用例结束后，控制器会检查所有剩余期望的调用是否满足条件。

控制器的代码如下所示：

mock 对象创建时需要注入控制器，如果有多个 mock 对象则注入同一个控制器，如下所示：

2.3.3. mock 对象的行为注入

对于 mock 对象的行为注入，控制器是通过 map 来维护的，一个方法对应 map 的一项。因为一个方法在一个用例中可能调用多次，所以 map 的值类型是数组切片。当 mock 对象进行行为注入时，控制器会将行为 Add。当该方法被调用时，控制器会将该行为 Remove。

假设有这样一个场景：先 Retrieve 领域对象失败，然后 Create 领域对象成功，再次 Retrieve 领域对象就能成功。这个场景对应的 mock 对象的行为注入代码如下所示：

objBytes 是领域对象的序列化结果，比如：

当批量 Create 对象时，可以使用 Times 关键字：

当批量 Retrieve 对象时，需要注入多次 mock 行为:

3. Monkey

至此，我们已经知道：

全局变量可通过 GoStub 框架打桩

过程可通过 GoStub 框架打桩

函数可通过 GoStub 框架打桩

interface 可通过 GoMock 框架打桩

但还有两个问题比较棘手：

方法（成员函数）无法通过 GoStub 框架打桩，当产品代码的 OO 设计比较多时，打桩点可能离被测函数比较远，导致 UT 用例写起来比较痛

过程或函数通过 GoStub 框架打桩时，对产品代码有侵入性

Monkey 是 Golang 的一个猴子补丁（monkeypatching）框架，在运行时通过汇编语句重写可执行文件，将待打桩函数或方法的实现跳转到桩实现，原理和热补丁类似。通过 Monkey，我们可以解决函数或方法的打桩问题，但 Monkey 不是线程安全的，不要将 Monkey 用于并发的测试中。

Monkey 框架的使用场景很多，依次为：

基本场景：为一个函数打桩

基本场景：为一个过程打桩

基本场景：为一个方法打桩

复合场景：由任意相同或不同的基本场景组合而成

特殊场景：桩中桩的一个案例

另有 GoMonkey 框架https://github.com/agiledragon/gomonkey，对比Monkey来说，写法更简单，有兴趣的读者可以尝试使用。

3.1. 为一个函数打桩

Exec 是 infra 层的一个操作函数，实现很简单，代码如下所示：

Monkey 的 API 非常简单和直接，我们直接看打桩代码：

Patch 是 Monkey 提供给用户用于函数打桩的 API：

第一个参数是目标函数的函数名

第二个参数是桩函数的函数名，习惯用法是匿名函数或闭包

返回值是一个 PatchGuard 对象指针，主要用于在测试结束时删除当前的补丁

3.2. 为一个过程打桩

当一个函数没有返回值时，该函数我们一般称为过程。很多时候，我们将资源清理类函数定义为过程。我们对过程 DestroyResource 的打桩代码为：

3.3. 为一个方法打桩

当微服务有多个实例时，先通过 Etcd 选举一个 Master 实例，然后 Master 实例为所有实例较均匀的分配任务，并将任务分配结果 Set 到 Etcd，最后 Master 和 Node 实例 Watch 到任务列表，并过滤出自身需要处理的任务列表。

我们用类 Etcd 的方法 Get 来模拟获取任务列表的功能，入参为 instanceId：

我们对 Get 方法的打桩代码如下：

PatchInstanceMethod API 是 Monkey 提供给用户用于方法打桩的 API：

在使用前，先要定义一个目标类的指针变量 x

第一个参数是 reflect.TypeOf(x)

第二个参数是字符串形式的函数名

返回值是一个 PatchGuard 对象指针，主要用于在测试结束时删除当前的补丁

四、Mock 场景最佳实践

1. 实例函数 Mock：Monkey

Monkey 用于对依赖的函数进行 Mock 替换，从而可以完成仅针对当前模块的单元测试。

例子：

包是真实的函数包是即将用于 mock 的函数

:

:

:

2. 未实现函数 Mock：GoMock

假设场景：公司、人。

公司可以开会。

公司内部的人继承了讨论者接口，拥有说话的方法。

假如现在要测试这个场景，在所有类都实现的情况下，测试应该是这样的：

但现在类并未实现，则可以通过 GoMock 工具来模拟一个对象。

定义一个

根据该接口，用命令生成一个 Mock 对象

接着进行测试用例的编写：

: 新建 Mock 控制器

: 新建 Mock 对象，这里是调用 NewMockTalker()

：撰写一些断言测试

之前 Mock 建立的对象传入到待测方法当中

测试结果通过 testing 框架返回

3. 系统内置函数 Mock：Monkey

，用 Monkey 的 patch 来 mock 系统内置函数

如果需要取消替换，可以使用

4. 数据库行为 Mock

5. 服务器行为 Mock：Monkey

使用 net/http/httptest 模拟服务器行为

这里只使用了 Monkey 的 Patch 进行简单测试，但在更一般的情况下，更多的函数还是通过实例函数来编写的，对这部分函数要用才可以进行替换。

接收三个参数：

通过新建一个待测实例对象，调用 reflect 包的方法就可以得到

是待测实例对象的函数名

是用于替换的函数

实现如下：

假设有如下一个函数，用于接收用户名密码，向当前连接的服务器请求登陆，测试如下：

五、具体案例：聊天室

1. 概览

该项目是一个具有登录、查看在线用户、私聊、群聊等功能的命令行聊天室 Demo。

项目分为 Client、Server 子项目，都通过 model、Controllor(Processor）、View（Main）来进行功能划分。还有一个 Common 包放置通用性的工具类。

预期目的：对实现的功能模块补充单元测试代码，度量确保每一个模块的功能的正确性、完整性、健壮性，并在未来修改代码后也能第一时间自测验收。

单元测试应包括模块接口测试、模块局部数据结构测试、模块异常处理测试。

对于接口测试，应对接口的传入参数测试样例设计进行全面的考察，判断每一个参数是否有是有必要的，参数间有没有冗余，进入函数体前引用的指针是否有错等等。

对于局部数据结构测试，应检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整性、正确性。局部数据结构往往是错误的根源，应仔细设计测试用例。

对于异常处理，主要有如下几种常见错误：

输出的出错信息提示不足

对异常没有进行处理

出错信息与实际不相符

出错信息中未能准确定位出错信息

以上几种错误，都是模块中经常会出现的错误，要针对这些错误来进行边界条件测试检查，只有异常处理机制正确，日后软件的维护和迭代才会更加高效。

在本案例中，Model 层对服务层提供的接口不多，就，两个核心函数，在服务层对其进行封装抽象为具体的业务逻辑。由于涉及网络连接，所以对其进行的测试必须编写桩函数。在服务层，涉及到对多个网络连接调用、数据库调用其它模块依赖，所以也要为其进行 Mock。

由于涉及 Mock 和桩函数编写，可以使用、两个包进行这些工作，它们较简洁地实现了很多实用的测试方式，只需要用户编写依赖的接口文件、用于替换的 Mock 函数，就可以仅在测试过程中替换掉系统函数或者其它依赖的功能模块，使得单元测试起到它应有的作用。

2. Model 层、数据库相关测试

由于是单元测试，所以需要获取一个 Mock 数据库实例，测试增删改查 SQL 语句是否可执行。代码如下：

3. 私聊功能测试

由于涉及底层数据库交互时需要发送 JSON 转码字符串（函数），因此将其 Mock 处理，只需关注本函数逻辑是否正确即可。如下：

4. 登录功能测试

登录涉及服务器连接操作，服务器的连接逻辑可通过包来进行检测，Mock 一个 HTTP 连接，示例代码如下：

为登录模块编写用于测试替换的函数以及单元测试主体，代码如下：

5. 工具类测试

6. 项目总结

在编写桩模块时会发现，模块之间的调用关系在工程规模并不大的本案例中，也依然比较复杂，需要开发相应桩函数，代码量会增加许多，也会消耗一些开发人员的时间，因此反推到之前流程的开发实践中，可以得出结论就是提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

Go 单元测试框架是相当易用的，其它的第三方库基本都是建立在 testing 原生框架的基础上进行的增补扩充，在日常开发中，原生包可以满足基本需求，但同样也有缺陷，原生包不提供断言的语法使得代码中的这种片段非常多：

所以引入了 convey、assert 包的断言语句，用于简化判断逻辑，使得程序更加易读。

在完成项目单测时，遇到了不少问题，比较重要的比如由于架构分层不够清晰，还是有部分耦合代码，导致单测时需要屏蔽的模块太多，代码写起来不便。因此还是需要倒推到开发模块之前，就要设计更好的结构，在开发的过程中遵循相应的规则，通过测试先行的思想，使开发的工程具有更好的可测试性。

开发过程中遇到的场景肯定不局限于本文所讨论的范围，有关更丰富的最佳实践案例可以参照：

六、结语

1. 实践小结

单元测试大多是由开发人员进行编写，本篇文章旨在指引，不在于面面俱到，具体的单元测试框架的使用语法，开发同学可以自行 Google。

以测试的角度，推行单元测试是不易的，最佳的方式莫过于开发人员，在一定的指引之后，以实际项目出发进行实践，然后自行总结具体的 case，有针对性、有感染力进行内部分享，测试同学及时提供测试用例的指引和规范的约束。

2. 特别鸣谢

两位实习生罗宇韬和钟梓轩，在暑假实习期间，协助整理了 Golang 单测的代码示例。