大家好，我是 “潇洒哥老苗”。
该系列上篇讲解了 《并发》 ，今天我们学学 Go 语言中的单元测试。
依赖 Go 版本：1.16.4。
源码地址：
https://github.com/miaogaolin/gobasic
学到什么
- 什么是单元测试？
- 如何编写单元测试？
- 什么是代码覆盖率？
- 如何使用 testify 包？
引入
先不讲解 “单元测试” 的概念，在不使用 “单元测试” 的情况下，我们如何测试一个函数或方法的正确性。
例如，如下函数：
// gobasic/unittest/add.go
func Add(num1, num2 int) int {
return num1 + num2
}
这个函数逻辑很简单，只进行 num1 和 num2 两数的相加。在实际开发中对这样的逻辑没必要进行单元测试，现在咱就假设这个函数逻辑很复杂，需要测试才知道对不对。
测试如下：
package main
import "fmt"
func main() {
excepted := 5
actual := Add(2, 3)
if excepted == actual {
fmt.Println("成功")
} else {
fmt.Println("失败")
}
}
对于这样的测试方式，它有如下问题：
- 测试代码和业务代码混乱、不分离；
- 测试完后，测试代码必须删除；
- 如果不删除，会参与编译。
你可能会说，可以使用 debug 方式测试，但这样，没有任何测试过程，后期如果修改了代码，如何确定当时什么样的结果是正确的。
下来，引入 “单元测试” 的概念，以解决上述所说的问题。
什么是单元测试
根据维基百科的定义，单元测试又称为模块测试，是针对程序模块（软件设计的最小单元）来进行正确性检验的测试工作。
在 Go 语言中，测试的最小单元常常是函数和方法。
测试文件
简单了解了概念后，现在就开始创建一个单元测试文件。
在很多语言中，常常把测试文件放在一个独立的目录下进行管理，而在 Go 语言中会和源文件放置在一块，即同一目录下。
例如，对于上面的 Add 函数，所在文件是 add.go，那创建的测试文件也和它放在一块，如下：
- unitest 目录
- add.go
- add_test.go 单元测试
假如源文件的命名是 xxx.go, 那单元测试文件的命名则为 xxx_test.go。如果在编译阶段 xxx_test.go 文件会被忽略。
写单元测试
下来我们一块在 add_test.go 文件中给 Add 函数写一个单元测试。
1. 基本结构
先看看基本结构，具体的测试内容没写，如下：
// gobasic/unittest/add_test.go
package unittest
import "testing"
func TestAdd(t *testing.T) {
// ...
}
-
导入 testing 标准包；
-
创建一个 Test 开头的函数名 TestAdd，Test 是固定写法，后面的 Add 一般和你要测试的函数名对应，当然不对应也没有问题；
-
参数类型
*tesing.T用于打印测试结果，参数中也必须跟上。
所有的单元测试函数都要按照该要求定义，定义好后，下来看看如何编写测试内容。
2. 测试内容
测试 Add 函数的计算结果是否正确。
// gobasic/unittest/add_test.go
package unittest
import "testing"
func TestAdd(t *testing.T) {
excepted := 4
actual := Add(2, 3)
if excepted != actual {
t.Errorf("excepted：%d, actual:%d", excepted, actual)
}
}
- excepted 函数期待的结果；
- actual 函数真实计算的结果；
- 如果不相等，打印出错误。
在 unittest 目录下运行 go test （或 go test ./）命令，表示运行 unittest 目录下的单元测试，不会再往下递归。如果想往下递归，即当前目录下还有目录，则运行 go test ./... 命令。
运行结果：
$ go test
--- FAIL: TestAdd (0.00s)
add_test.go:11: excepted：4, actual:5
FAIL
FAIL github.com/miaogaolin/gobasic/unittest 0.228s
FAIL
结果中看出 TestAdd 函数运行失败，并打印出了错误行数 11 和 组装的日志。
假如你使用了 Goland 工具，直接点击下图的红框位置即可。
*testing.T
现在对参数类型 T 中的几个方法展开说说，如下：
-
Error打印错误日志、标记为失败 FAIL，并继续往下执行。 -
Errorf格式化打印错误日志、标记为失败 FAIL，并继续往下执行。 -
Fail不打印日志，结果中只标记为失败 FAIL，并继续往下执行。 -
FailNow不打印日志，结果中只标记为失败 FAIL，但在当前测试函数中不继续往下执行。 -
Fatal打印日志、标记为失败，并且内部调用了 FaileNow 函数，也不往下执行。 -
Fatalf格式化打印错误日志、标记为失败，并且内部调用了 FaileNow 函数，也不往下执行。
你可能发现，没有成功的方法，不过确实也没有，只要没有通知错误，那就说明是正确的。正确的测试结果是下面这个样子：
$ go test
ok github.com/miaogaolin/gobasic/unittest 0.244s
测试资源
有时候在你写单元测试时，可能需要读取文件，那这些相关的资源文件就放置在 testdata 目录下。
示例：
- unittest 目录
- xxx.go
- xxx_test.go
- testdata 目录
go test 和 go vet
在运行 go test 命令后，go vet 命令也会自动运行。
简单说下 go vet 命令，本篇不过多描述。它用于代码的静态分析，检查编译器检查不出的错误，例如：
// gobasic/vet/main.go
package main
import "fmt"
func main() {
fmt.Printf("%d", "miao")
}
// 输出
%!d(string=miao)
看结果是不是很奇怪，是因为占位符 %d 需要的是整数，但给的是字符串。不熟悉占位符的朋友，直接前往 《详解 20 个占位符》 。
对于这种类似的错误，编译器是不会报错的，这时候就用到了 go vet 命令，运行如下：
$ go vet
# github.com/miaogaolin/gobasic/vet
.\main.go:6:2: Printf format %d has arg "miao" of wrong type string
所以在测试时无需单独运行 go vet 命令，一个 go test 命令就包含了。
表格驱动测试
在对于一个函数或方法进行测试时，很多时候要测试多种情况，那对于多种情况如何进行测试呢？下来看看。
// gobasic/unittest/add_test.go
package unittest
import "testing"
func TestAdd1(t *testing.T) {
excepted := 5
actual := Add(2, 3)
if excepted != actual {
t.Errorf("case1：excepted：%d, actual:%d", excepted, actual)
}
excepted = 10
actual = Add(0, 10)
if excepted != actual {
t.Errorf("case2：excepted：%d, actual:%d", excepted, actual)
}
}
通过上述代码，我们可以看出，如果遇到多种情况时，再使用 if 语句判断即可。你可能心里会嘀咕： “这还用你说，不是废话吗！”。
下来开始我真正想说的，如果我们想要测试的情况比较多，按照上面这种写法看起来就会很冗余，所以我们改为下面的写法：
// gobasic/unittest/add_test.go
package unittest
import "testing"
func TestAddTable(t *testing.T) {
type param struct {
name string
num1, num2, excepted int
}
testCases := []param{
{name: "case1", num1: 2, num2: 3, excepted: 5},
{name: "case2", num1: 0, num2: 10, excepted: 10},
}
for _, v := range testCases {
t.Run(v.name, func(t *testing.T) {
actual := Add(v.num1, v.num2)
if v.excepted != actual {
t.Errorf("excepted:%d, actual:%d", v.excepted, actual)
}
})
}
}
- 通过切片保存每种想要测试的情况（测试用例），下来只需要通过循环判断即可；
t.Run方法，第一个参数是当前测试的名称，第二个是个匿名函数，用来写判断逻辑。
运行结果：
$ go test add.go add_test.go -test.run TestAddTable -v
=== RUN TestAddTable
=== RUN TestAddTable/case1
=== RUN TestAddTable/case2
--- PASS: TestAddTable (0.00s)
--- PASS: TestAddTable/case1 (0.00s)
--- PASS: TestAddTable/case2 (0.00s)
PASS
ok command-line-arguments 0.041s
go test命令后的 add.go 和 add_test.go 文件是特意指定需要测试和依赖的文件；-test.run指明测试的函数名；-v展示详细的过程，如果不写，测试成功时，不会打印详细过程。
缓存
当运行单元测试时，测试的结果会被缓存下来。如果更改了测试代码或源文件，则会重新运行测试，并再次缓存。
但不是任何情况都可以缓存下来，只有当 go test 命令后跟着目录、指定的文件或包名才可以，举例如下：
- go test ./
- go test ./pkg
- go test add.go add_test.go
- go test fmt
如果我在 unittest 目录下运行测试，第一次和第二的结果如下：
# 第一次
$ go test ./
ok github.com/miaogaolin/gobasic/unittest 0.228s
# 第二次
$ go test ./
ok github.com/miaogaolin/gobasic/unittest (cached)
可以看到第二次的结果中出现了 cached 字样，如果你问 “删掉后面的 ./” 可以吗？答：不可以，因为不会进行缓存。
1. 禁用缓存
如果想禁用缓存，可以使用如下命令运行：
go test ./ -count=1
2. 其它情况
上面说过，当单元测试文件或源文件修改时，会重新缓存。
但还有其它情况也会如此，比如当你的单元测试中涉及了如下情况：
- 读取环境变量的内容更改
- 读取文件的内容更改
这两种情况不会影响测试文件和源文件的修改，但还是会重新缓存测试结果。
并发测试
为了提高多个单元测试的运行效率，我们可以采取并发测试。先看一个没有并发的例子，如下：
func TestA(t *testing.T) {
time.Sleep(time.Second)
}
func TestB(t *testing.T) {
time.Sleep(time.Second)
}
func TestC(t *testing.T) {
time.Sleep(time.Second)
}
该例子中没有写任何具体的测试逻辑，只是每个函数休眠了 1s 中，目的只是演示测试的时间。
测试结果如下：
ok command-line-arguments 3.242s
可以看到总共花费了 3.242s。
下来加入并发，如下：
func TestA(t *testing.T) {
t.Parallel()
time.Sleep(time.Second)
}
func TestB(t *testing.T) {
t.Parallel()
time.Sleep(time.Second)
}
func TestC(t *testing.T) {
t.Parallel()
time.Sleep(time.Second)
}
在每个测试函数前增加了 t.Parallel() 实现并发。
测试如下：
ok command-line-arguments 1.049s
很明显可以看到，测试的时间缩短到了 1s，大概是原来时间的三分之一。
代码覆盖率
代码覆盖率是一个指数，例如：20%、30% 、100% 等。
它体现了你的项目代码是否得到了足够的测试，指数越大，说明测试的覆盖情况越全面。
命令如下：
$ go test -cover
PASS
coverage: 100.0% of statements
ok github.com/miaogaolin/gobasic/unittest 1.045s
-cover输出覆盖率的标识符；- 覆盖率为 100%，说明被测试的函数代码都有运行到，覆盖率 = 已执行语句数 / 总语句数。
在计算覆盖率时，还有三种模式，不同的模式在已执行语句的次数统计时存在差异性。
1. 模式 set
这是默认的模式，它的计算方式是 “如果同一语句多次执行只记录一次”。
举例看个例子，如下：
func GetSex(sex int) string {
if sex == 1 {
return "男"
} else {
return "女"
}
}
下来给这个函数写个单元测试，如下：
func TestGetSex(t *testing.T) {
excepted := "男"
actual := GetSex(1)
if actual != excepted {
t.Errorf("excepted：%s, actual:%s", excepted, actual)
}
}
我就不解释这个测试函数了，你很聪明的。
运行覆盖率命令：
$ go test -cover
ok command-line-arguments 0.228s coverage: 66.7% of statements
这次的覆盖率可不是 100% 了，那为啥是 66.7%，往下看。
在终端运行如下命令：
go test -coverprofile profile
运行后，会在当前目录生成一个覆盖率的采样文件 profile，打开内容如下：
mode: set
github.com/miaogaolin/gobasic/testcover/sex.go:3.29,4.14 1 1
github.com/miaogaolin/gobasic/testcover/sex.go:4.14,6.3 1 1
github.com/miaogaolin/gobasic/testcover/sex.go:6.8,8.3 1 0
暂时先不介绍这个文件内容细节，先使用这个文件生成一个直观图，命令如下：
go tool cover -html profile
-html profile 指明将 profile 文件在浏览器渲染出来，运行后会自动在浏览器出现如下图：
灰色不用管，绿色的已覆盖，红色的未覆盖。
下来回到 profile 文件的内容，看图说明：
- 第一行，覆盖率模式；
- 剩下三行，对应下图不同颜色的下划线。
可得：总语句数为 3，覆盖语句（执行语句）数为 2，计算覆盖率为 2/3 = 66.7%。
如果想达到 100% 覆盖，只需要增加 else 的测试情况，如下：
func TestGetSex2(t *testing.T) {
excepted := "女"
actual := GetSex(0)
if actual != excepted {
t.Errorf("excepted：%s, actual:%s", excepted, actual)
}
}
2. 模式 count
该模式和 set 模式比较相似，唯一的区别是 count 模式对于相同的语句执行次数会进行累计。
使用下面命令生成 profile 文件：
go test -coverprofile profile -covermode count
这次测试，会将 TestGetSex 和 TestGetSex2 函数都运行，自然也会 100% 覆盖。
profile 文件内容：
mode: count
github.com/miaogaolin/gobasic/testcover/sex.go:3.29,4.14 1 2
github.com/miaogaolin/gobasic/testcover/sex.go:4.14,6.3 1 1
github.com/miaogaolin/gobasic/testcover/sex.go:6.8,8.3 1 1
如果再切换到 set 模式下生成，唯一不同点是，内容第二行中的最后一个数字 2 在set 模式下会是 1。
那 count 模式下为啥是 2 呢？
因为 if sex == 1 语句被执行了两次，看下图再说明下：
- 执行 TestGetSex 和 TestGetSex2 函数时，
if sex == 1都会被执行一次，因此总共 2 次，而剩下的语句只执行了 1 次。 - 绿色表示覆盖率最高，下来是 low coverage 对应的颜色，表示低覆盖率。
总结，count 模式下能看出哪些代码执行的次数多，而 set 模式下不能。
3. 模式 atomic
该模式和 count 类似，都是统计执行语句的次数，不同点是，在并发情况下 atomic 模式比 count 模式计数更精确。
来看一个没啥用的并发例子，测试两者统计的结果，如下：
// gobasic/testatomic/nums.go
package testatomic
import "sync"
func AddNumber(num int) int {
var wg sync.WaitGroup
for i := 0; i < 200; i++ {
wg.Add(1)
go func(i int) {
i += num
wg.Done()
}(i)
}
wg.Wait()
return num
}
该代码创建了 200 个 Goroutine，再对 200 个数并发的与 num 参数相加。
单元测试的代码就不写了，只要调用了该函数就可以。如果想看，直接在 Github 上看完整代码。
count 模式下生成的 profile 文件内容如下：
mode: count
github.com/miaogaolin/gobasic/testatomic/nums.go:5.29,8.27 2 1
github.com/miaogaolin/gobasic/testatomic/nums.go:15.2,16.12 2 1
github.com/miaogaolin/gobasic/testatomic/nums.go:8.27,10.18 2 200
github.com/miaogaolin/gobasic/testatomic/nums.go:10.18,13.4 2 199
直接看最后一行，对应到源码上是 Goroutine 的代码块，即：go func(i int) {...}。
199 表示的是该语句的执行次数，但循环次数总共是 200 次，所以是不准确的。
那再以 atomic 模式运行，命令如下：
go test -coverprofile profile -covermode atomic
profile 文件内容如下：
mode: atomic
github.com/miaogaolin/gobasic/testatomic/nums.go:5.29,8.27 2 1
github.com/miaogaolin/gobasic/testatomic/nums.go:15.2,16.12 2 1
github.com/miaogaolin/gobasic/testatomic/nums.go:8.27,10.18 2 200
github.com/miaogaolin/gobasic/testatomic/nums.go:10.18,13.4 2 200
直接看内容的最后一个数字，这下正确了。
testify 包
当对一个项目中写大量的单元测试时，如果按照上述的方式去写，就会产生大量的判断语句。
例如这样的 if 判断：
func TestAdd(t *testing.T) {
excepted := 4
actual := Add(2, 3)
if excepted != actual {
t.Errorf("excepted：%d, actual:%d", excepted, actual)
}
}
下来我推荐一个第三方包 testfiy，首先在终端运行如下命令，表示下载该包。
go get github.com/stretchr/testify
改写单元测试代码，如下：
package unittest
import (
"github.com/stretchr/testify/assert"
"testing"
)
func TestAdd(t *testing.T) {
excepted := 4
actual := Add(2, 3)
assert.Equal(t, excepted, actual)
}
- 导入 testify 包下的一个子包 assert；
- 使用
assert.Equal函数简化 if 语句和日志打印，该函数期待 excepted 和 actual 变量相同，如果不相同会打印失败日志。
看看失败是啥样子，如下：
--- FAIL: TestAdd (0.00s)
add_test.go:11:
Error Trace: add_test.go:11
Error: Not equal:
expected: 4
actual : 5
Test: TestAdd
FAIL
FAIL command-line-arguments 0.578s
FAIL
也是打印出了期待的值和实际的值，并说明了两值不相等。
当然该包也不只有 Equal 函数，这个学习就留给自己了，相信你可以的。
小结
本篇讲解了 Go 语言中如何写单元测试，并讲了代码覆盖率的 3 种统计方式，对于如何给函数和方法写单元测试，一定要掌握。
如果在测试代码时发现了和我所写的结果有出入，那可能就是版本差异。
有问题的话，随意讨论。