云原生系列Go语言篇-编写测试

本文来自正在规划的Go语言&云原生自我提升系列，欢迎关注后续文章。

2000年以来，自动化测试的广泛应用可能比任何其他软件工程技术都更能提高代码质量。Go是一种专注于提高软件质量的语言和生态系统，很自然的在其标准库中包含了测试支持。Go中测试代码非常容易，没有理由不添加测试。本章中，读者将了解如何测试Go代码，将测试分组为单元测试和集成测试，检查测试代码覆盖率，编写基准测试，并学习如何使用Go竞态检查器检测代码的并发问题。同时，还会讨论如何编写可测试的代码，以及为什么它会提高我们的代码质量。

测试的基础知识

Go的测试支持由两部分组成：库和工具。标准库中的testing包提供了编写测试所需的类型和函数，而Go包中的go test工具可运行测试并生成报告。与许多其他语言不同，Go的测试放在与生产代码相同的目录和相同的包中。由于测试位于同一包中，它们能够访问和测试未导出的函数和变量。读者很快就会学到如何编写仅测试公开API的测试。

注：本章的完整代码示例请见第15章的GitHub代码库。

下面编写一个简单的函数，然后编写测试来确保该函数正常运行。在sample_code/adder目录中的文件adder.go中添加如下代码：

相应的测试为adder_test.go：

测试文件都以_test.go结尾。如要为foo.go编写测试，可将测试放在名为foo_test.go的文件中。

测试函数以Test开头，并接收一个类型为*testing.T的参数。按照惯例，该参数被命名为t。测试函数不返回任何值。测试的名称（不含开头的“Test”）用于记录正在进行测试的内容，因此请选择能说明您正在测试内容的名称。在为单独的函数编写单元测试时，惯例是将单元测试命名为Test后接函数的名称。在测试未导出函数时，有些人会在Test和函数名称之间使用下划线。

此外，请注意使用标准的Go代码来调用正在进行测试的代码，并验证响应是否与预期一致。当结果不正确时，可以使用t.Error方法报告错误，使用方式类似于fmt.Print函数。读者很快会学到其他报告错误的方法。

刚刚了解了Go测试支持库的部分。下面来看看工具部分。就像go build用于构建二进制文件、go run用于运行文件一样，命令go test用于运行当前目录中的测试函数：

貌似我们发现了代码中的bug。仔细观察addNumbers，发现我们使用x加x，而不是x加y。下面修改代码重新运行测试看bug是否已修复：

go test命令允许我们指定要测试的包。使用./...作为包名称表示要运行当前目录以及其所有子目录中的测试。添加-v标记获取详细的测试输出。

报告测试失败

*testing.T有几个报告测试失败的方法。我们已经用过Error，它将一组逗号分隔的值构建成一个失败描述字符串。

如果读者更乐意使用类似Printf的格式化字符串来生成消息，请改用Errorf方法：

虽然Error和Errorf标记测试为失败，但测试函数会继续运行。如果觉得测试函数应该在发现失败后立即停止处理，使用Fatal和Fatalf方法。Fatal方法类似于Error，而Fatalf方法类似Errorf。不同之处在于，在生成测试失败消息后，测试函数会立即退出。注意，它不会退出所有测试；在当前测试函数退出后，剩余的测试函数都将继续执行。

何时该使用Fatal/Fatalf，何时该使用Error/Errorf呢？如果测试中的某个检查失败表示同一测试函数中的后续检查也将失败或导致测试panic，那么请使用Fatal或Fatalf。如果测试多个独立的项目（例如验证结构体中的字段），那么请使用Error或Errorf，这样可同时报告多个问题。也就可以更轻松地修复多个问题，而无需一次又一次地反复运行测试。

设置和清理

有时可能希望在运行测试之前设置一些通用状态，并在测试完成时将其删除。使用TestMain函数来管理该状态并运行测试：

TestFirst和TestSecond都引用了包级变量testTime。正确运行测试需要对其进行初始化。我们声明了一个名为TestMain的函数，其参数类型为*testing.M。如果包中有名为TestMain的函数，go test会去调用它，而不是其它测试函数。TestMain函数的责任是设置包中的测试正常运行所需的所有状态。一旦配置了状态，TestMain函数会在*testing.M上调用Run方法。这会运行包中的测试函数。Run方法返回退出码；0表示所有测试全部通过。最后，TestMain函数必须使用Run返回的退出码调用os.Exit。

运行go test输出如下：

注：请注意，TestMain只会调用一次，不会在每个单独的测试之前和之后都调用。此外，请注意每个包只能有一个TestMain。

一般在两种常见情况下使用TestMain：

1. 需要在外部存储（如数据库）中设置数据时。
2. 测试的代码依赖于需初始化的包级变量时。

前面已提到（还会再次提到！），应避免在程序中使用包级变量。那会让我们难以理解数据如何在程序中流动。如果出于这个原因使用TestMain，请考虑重构代码。

*testing.T上的Cleanup方法用于清理为单个测试创建的临时资源。该方法有一个参数，即没有输入参数或返回值的函数。该函数在测试完成时运行。对于简单的测试，可使用defer语句来实现相同的结果，但是当测试依赖于帮助函数来设置示例数据时，如例12-1，Cleanup非常有用。可以多次调用Cleanup，和defer一样，函数按照最后添加最先调用的顺序调用。

例12-1 使用t.Cleanup

如果测试中使用了临时文件，您可以利用*testing.T上的TempDir方法，无需编写清理代码。每次调用此方法时，都会新建一个临时目录，并返回目录的完整路径。它还会在测试完成时使用Cleanup注册一个处理程序，删除目录及其内容。可以使用它重写上面的示例：

使用环境变量进行测试

使用环境变量来配置应用程序是一种常见（也是非常好的）做法。为有助测试环境变量解析代码，Go在testing.T上提供了一个帮助方法。调用t.Setenv()可为测试注册环境变量的值。在背后，它会在测试退出时调用Cleanup，将环境变量恢复到其先前的状态。

注：虽然使用环境变量来配置应用程序是好做法，但也应确保大部分代码完全不知道它们的存在。在程序开始运行之前，确保将环境变量的值复制到配置结构体中，可以在main函数或其后的位置实现。这样做可以更易于重用和测试代码，因为代码的配置方式已经从代码的实际功能抽象出来了。

相比自己编写这些代码，强烈建议考虑使用第三方配置库，比如Viper或envconfig。此外，可以考虑使用GoDotEnv将环境变量存储在.env文件中，以供开发或持续集成机器使用。

存储样本测试数据

在go test遍历源代码树时，它将当前包目录用作工作目录。如果想要使用样本数据来测试包中的函数，请创建一个名为 testdata 的子目录来存储文件。Go 保留此目录名称作为保存测试文件的位置。在从 testdata 读取时，保持使用相对文件引用。由于go test会将当前工作目录更改为当前包，每个包会通过相对文件路径访问自己的 testdata。

小贴士：text包演示了如何使用 testdata。

缓存测试结果

就像在模块、包和导入中学到的那样，如果编译的包没有更改，Go 会将其缓存起来，在跨包运行测试时，如果测试已经通过且其代码没有更改，Go 也会缓存测试结果。如果修改了包中的任何文件或 testdata 目录中的文件，测试将被重新编译并重新运行。如果传递标记 -count=1给 go test，还可以强制测试始终运行。

测试公开API

我们编写的测试与生产代码位于同一个包中。这样能够测试导出和未导出的函数。

如果只想测试包的公开API，Go 有一种约定来进行指定。依然将测试源代码保存在与生产源代码相同的目录中，但使用 packagename_test 作为包名。重新执行我们最初的测试案例，这次使用一个已导出的函数。代码位于第15章的GitHub代码库中的 sample_code/pubadder 目录中。如果在 pubadder 包中有以下函数：

那么可以使用pubadder包中 adder_public_test.go文件的如下代码测试公开API：

请注意，我们测试文件的包名为 pubadder_test。尽管这些文件位于同一个目录中，我们仍需要导入 github.com/learning-go-book-2e/ch15/sample_code/pubadder。为遵循测试命名的约定，测试函数的名称与 AddNumbers 函数的名称相匹配。另外注意，我们使用了 pubadder.AddNumbers，因为是在不同的包中调用了一个已导出的函数。

小贴士：如果手动输入此代码，需要创建一个带有模块声明文件go.mod的模块：

module github.com/learning-go-book-2e/ch15

1	module github.com/learning-go-book-2e/ch15

并将源代码放在模块的 sample_code/pubadder 目录中。

正如可以从包内部调用已导出的函数一样，也可以从源代码同一个包中的测试中测试公开API。在包名中使用_test后缀的优势是，可以将所测试的包视为“黑盒”。只能通过其导出的函数、方法、类型、常量和变量与其进行交互。还要注意，可以在同一源代码目录中交叉使用两个包名的测试源文件。

使用go-cmp比较测试结果

编写两个复合类型实例之间的完整比较可能会很冗长。虽然我们可以使用reflect.DeepEqual来比较结构体、字典和切片，但还有一种更好的方法。Google 发布了一个名为 go-cmp的第三方模块，它可以做这种比较，并返回不匹配内容的详细描述。我们通过定义一个简单的结构体和一个为其赋值的工厂函数来看看是如何使用的。代码位于第15章的GitHub代码库的 sample_code/cmp 目录中：

在测试文件中，需要导入github.com/google/go-cmp/cmp，测试函数如下：

cmp.Diff函数接收期望输出和待测试函数返回的输出作为参数。它返回一个字符串，描述这两个输入之间的不匹配之处。如果输入匹配，它将返回一个空字符串。将cmp.Diff函数的输出赋给一个名为 diff 的变量，然后检测 diff 是否为空字符串。如果不为空，就表示发生了错误。

在构建并运行测试时，会看到go-cmp在两个结构体实例不匹配时生成的输出：

以-和 +开头的行表示值不同的字段。这里测试失败是因为时间不匹配。这是一个问题，因为您无法控制 CreatePerson函数所赋的时间。需要忽略 DateAdded 字段。通过指定一个比较函数来实现。在测试中将该函数声明为一个局部变量：

将一个函数传递给cmp.Comparer函数，以创建一个自定义比较器。传入的函数两个参数必须为相同类型，并返回一个布尔值。它还必须是对称的（参数的顺序无关紧要）、确定性的（对于相同的输入，始终返回相同的值）和纯粹的（不能修改其参数）。在我们的实现中，比较 Name 和 Age 字段，忽略 DateAdded 字段。

然后修改调用cmp.Diff的代码，包含comparer：

这只是对go-cmp最有用特性的快速概览。参见其官方文档学如何控制比较内容和输出格式。

表格测试

大多数情况下，验证函数是否正确运行通常需要多个测试用例。可以编写多个测试函数来验证该函数，或者在同一个函数内编写多个测试，但你会发现大部分测试逻辑是重复的。需要设置支持数据和函数，指定输入，检查输出，并进行比较以查看它们是否符合预期。与其一遍又一遍地编写这些内容，不如利用一种称为表格测试的模式。我们来看一个示例。代码们于第15章的GitHub代码库的 sample_code/table 目录中。假设我们在 table 包中有以下函数：

要测试该函数，需要检查不同的分支，尝试返回有效结果的输入，以及触发错误的输入。可以编写如下代码，但这非常繁复：

我们改用表格测试。首先，声明一个匿名结构体切片。结构体包含测试的名称、入参和返回值的字段。切片中的每条代表一个测试：

接着，循环遍历data中的每个测试用例，每次调用 Run 方法。这是有魔法的一行代码。我们向 Run 传递两个参数，一个子测试的名称，和一个带有类型为*testing.T的单个参数的函数。在函数内部，我们使用data中当前条目的字段调用 DoMath，一遍又一遍地使用相同的逻辑。在运行这些测试时，不仅会看到它们通过了，而且当您使用-v标记时，每个子测试都有一个名称：

小贴士：比较错误消息很不可靠，因为可能没有对消息文本的兼容性保证。我们正在测试的函数使用errors.New和 fmt.Errorf 创建错误，因此唯一的选择是比较消息。如果错误为自定义类型，请使用errors.Is或errors.As来检查是否返回了正确的错误。

有了运行大量测试的方法，下面了解一下测试代码的覆盖率。

并发运行测试

默认情况下，单元测试是顺序运行的。由于每个单元测试应与其他单元测试相互独立，进行并发测试非常理想。要使单元测试与其他测试并发运行，可在测试中的第一行调用*testing.T上的 Parallel 方法：

并行测试与其他标记为并行的测试并发运行。

并行测试的优势在于它可以加速运行时间较长的测试套件。但也有一些缺点。如果有多个依赖于相同共享可变状态的测试，请不要将它们标记为并行，因为会得到不一致的结果。（但在所有这些警告之后，你的应用程序中没有任何共享可变状态吧？）此外，还要注意，如果将测试标记为并行并在测试函数中使用 Setenv 方法，测试会 panic。

在并行运行表格测试时要小心。当表格测试并行运行时，就像我们在 for 循环中启动了多个 goroutine 一样。在这个示例中，变量d的引用被所有并行测试共享，因此它们都看到相同的值：

可在The Go Playground中运行这段代码或是通过第15章的GitHub代码库的 sample_code/parallel 目录获取代码。查看输出会看到对表格测试中最后的值进行了三次测试：

要避免这一问题，在for循环中调用t.Run前遮蔽d：

检测代码覆盖率

代码覆盖率是一个非常有用的工具，可以知道是否漏掉了某些明显的状况。但达到100%的测试覆盖率并不能保证在某些输入下代码中没有错误。首先，我们会学习如何使用go test展示代码覆盖率，然后我们会了解仅依赖代码覆盖率的局限性。

在go test命令中添加-cover标记可以计算覆盖率信息，并在测试输出中添加摘要。如果再加上一个-coverprofile 的参数，可将覆盖率信息保存到一个文件中。我们再回到第15章的GitHub代码库的sample_code/table目录中，收集代码覆盖率信息：

如果检测表格测试的代码覆盖率，测试输出会显示一行信息，代码覆盖率为87.5%。虽然这是有用的信息，但我们更希望看到漏掉了哪些测试。Go 附带的cover工具会生成包含了这些信息的 HTML 表示：

运行该命令，应该会打开浏览器并能看到如图12-1的页面：

图12-1：初始测试代码覆盖率

每个测试过的文件都会出现在左上角的组合框中。源代码有三种颜色。灰色表不可测试的代码行，绿色表已被测试覆盖的代码，红色表未经测试的代码。通过观察颜色，可以看出我们没有对default分支编写测试，即对函数传递错误的运算符时。下面将这种情况添加到测试列表中：

重新运行go test -v -cover -coverprofile=c.out和go tool cover -html=c.out，可在图12-2中看到测试代码覆盖率为100%。

图12-2：最终测试代码覆盖率

代码覆盖率非常棒，但也有不足。虽然有100%的覆盖率，但代码中却有一个bug。不知读者有没有注意到？如果没有，可以添加另一个测试用例然后运行测试：

可以看到如下错误：

在乘法用例中有一处笔误。对乘法使用了加号。（复制、粘贴代码时要格外小心！）修改代码，再次运行go test -v -cover -coverprofile=c.out和go tool cover -html=c.out，测试会正常通过。

警告：代码覆盖率很有必要，但并不足够。覆盖率为100%的代码仍可能存在bug。

基准测试

确定代码是快或慢非常复杂。我们不用自己计算，应使用Go测试框架内置的基准测试。下面来看第15章的GitHub代码库sample_code/bench目录下的函数：

这个函数计算文件中的字数。它接收两个参数，文件名和用于读取文件的缓冲大小（稍后会讲到第二个参数的作用）。

在测试其速度前，应当测试代码运行是否正常。以下是简单的测试：

下面来看运行该函数需要多长时间。我们的目标是找出该使用多大的缓冲区读取文件。

注：在花时间坠入优化的深渊之前，请明确程序需要进行优化。如果程序已经足够快，满足了响应要求，并且使用的内存量在接受范围之内，那么将时间花在新增功能和修复bug上会更好。业务的需求决定了何为”足够快”和”接受范围之内”。

在 Go 中，基准测试是测试文件中以单词Benchmark开头的函数，它们接受一个类型为*testing.B的参数。这种类型包含了*testing.T的所有功能，以及用于基准测试的额外支持。首先看一个使用 1 字节缓冲区的基准测试：

blackhole 包级变量是有作用的。我们将 FileLen 的结果写入这个包级变量，以确保编译器不会自负到优化掉对 FileLen 的调用，而对基准测试产生破坏。

每个 Go 基准测试都必须有一个循环，从 0 迭代到 b.N。测试框架会一遍又一遍地调用我们的基准测试函数，每次传递更大的 N 值，直到确保时间结果准确为止。马上会在输出中看到这一点。

我们通过向go test传递-bench标记来运行基准测试。该标记接收一个正则表达式来描述要运行的基准测试名称。使用-bench=.来运行所有基准测试。第二个标记-benchmem在基准测试输出中包含内存分配信息。所有测试在基准测试之前运行，因此只有在测试通过时才能对代码进行基准测试。

以下是运行基准测试我电脑上的输出：

运行含内存分配信息的基准测试输出有5列。分别如下：

BenchmarkFileLen1-12

基准测试的名称，中间杠，加用于测试的GOMAXPROCS的值。

25

产生稳定输出运行测试的次数。

47201025 ns/op

该基准测试运行单次通过的时间，单位是纳秒(1秒为1,000,000,000纳秒)。

65342 B/op

基准测试单次通过所分配的字节数。

65208 allocs/op

基准测试单次通过堆上分配字节的次数。其值小于等于字节的分配数。

我们已经得到1字节缓冲的结果，下面来看使用其它大小缓冲所得到的结果：

和使用t.Run启动表格测试类似，我们使用b.Run启动不同输入的基准测试。作者电脑上的结果如下：

结果符合预期；随着缓冲区大小的增加，分配次数减少，代码运行速度更快，直至缓冲区大于文件的大小。当缓冲区大于文件大小时，会有额外的分配导致输出减慢。如果我们预期文件大致是这个大小，那么10,000 字节的缓冲区效果最佳。

但是有一个改动可以进一步提高性能。现在每次从文件获取下一组字节时都重新分配缓冲区。这是没必要的。如果我们在循环之前进行字节切片分配，然后重新运行基准测试，会看到提升：

现在分配的次数相同且较小，每个缓冲区大小仅需四次分配。有意思的是，我们现在可以作出权衡。如果内存紧张，可以使用较小的缓冲区大小，在牺牲性能的情况下节约内存。

Go代码性能调优

如果基准测试显示存在性能或内存问题，下一步是确定问题的具体原因。Go 包含了分析工具，可从正在运行的程序中收集 CPU 和内存使用数据，还有用于可视化和解释生成的数据的工具。甚至可以暴露一个 Web 服务端点，远程从运行的 Go 服务中收集分析信息。

讨论性能调优工具不在我们的范畴。线上有许多很好的资源提供相关信息。一个不错的起点是 Julia Evans 的博文使用 pprof 对 Go 程序做性能分析。

Go的桩代码(Stub)

截至目前，我们测试的函数都不依赖其他代码的。但这并不具代表性，因为大多数代码都存在依赖关系。我们学过Go提供了两种方式来抽象函数调用：定义函数类型和定义接口。这些抽象不仅有助写出模块化的生产代码，还有助于我们编写单元测试。

小贴士：在代码有抽象依赖时，编写单元测试会更容易！

来看第15章的GitHub代码库的sample_code/solver目录中示例代码。我们定义了一个名为 Processor 的类型：

其中字段的类型为MathSolver：

稍后我们会实现并测试MathSolver。

Processor还需要一个从io.Reader中读取表达式并返回计算值的方法：

下面编写代码测试ProcessExpression。首先，人们需要简单地实现Resolve方法以供测试：

接下来，我们编写使用这一stub的单元测试（生产代码还应测试错误消息，但这里为保持简洁省略该操作）：

再进行测试，一切正常。

虽然大部分Go接口仅有一到两个方法，但也有更多的。有时会发现有多个方法的接口。我们来看第15章的GitHub代码库sample_code/stub目录中的代码。假设有一个这样的接口：

在测试依赖于大型接口的代码，有两种模式。第一种是将接口内嵌到结构体中。在结构体中内嵌接口会自动在结构体中定义接口的所有方法。它不提供这些方法的具体实现，因此需要实现当前所需测试的方法。假设Logic是一个包含Entities类型字段的结构体：

假如想测试如下方法：

这个方法仅使用对Entities声明的一个方法，即GetPets。不必实现GetPets上的所有方法的stub来测试GetPets，我们可以编写一个仅实现所需测试方法的stub结构体来完成测试：

然后编写单元测试，将stub插入Logic：

（顺便提下，GetPetNames方法有一个bug。你发现了吗？即便是简单的方法有时也可能存在bug。）

警告：如在stub结构体中嵌入接口，请确保实现测试期间调用的所有方法！如调用未实现的方法，测试会panic。

如仅需为单个测试实现接口中的一个或两个方法，这种方法效果很好。但在需要对不同输入和输出的测试调用相同方法时，其缺点就会暴露出来。这时，需要在同一实现中包含每个测试的各种可能结果，或者为每个测试重新实现该结构体。这很快就会难以理解和维护。更好的解决方案是创建一个将方法调用代理到函数字段的stub结构体。对于Entities上定义的每个方法，我们在stub结构体中定义一个具有匹配签名的函数字段：

然后通过定义方法来让EntitiesStub实现Entities接口。在各方法中，我们调用相应函数字段。如：

创建好这一stub，就可以通过用于表格测试的数据结构体中的除非来支持不同测试用例中不同方法的实现：

我们在data的匿名结构体中添加了一个函数类型的字段。在每个测试用例中，都指定一个返回与GetPets相同数据的函数。通过这种方式编写测试桩，可以清楚地了解每个测试用例应该返回什么。每个测试运行时，我们都会实例化一个新的EntitiesStub，并将测试数据中的getPets赋值给EntitiesStub中的getPets函数字段。

模拟和桩测试

术语”模拟”（mock）和”桩”（stub）测试经常互换使用，但它们实际上是两个不同的概念。Martin Fowler，一个在与软件开发领域令人尊敬的前辈，写过一篇有关mock测试的博客文章，讲到了模拟和桩测试之间的区别。简言之，桩测试对给定的输入返回固定的值，而模拟测试则验证一组调用是否按照预期的顺序和预期的输入发生。

在示例中，我们使用测试桩来返回给定响应的固定值。读者可以手动编写自己的模拟测试，或者可以使用第三方库来生成。最流行的两个是Google的gomock库和Stretchr的testify库。

httptest

为调用HTTP服务的函数编写测试可能会很困难。过去这会成为一个集成测试，需要启动一个作为函数调用的服务的测试实例。Go标准库内置net/http/httptest包，可以更容易地生成HTTP服务的测试桩。我们回到第15章的GitHub代码库的sample_code/solver目录，实现一个调用HTTP服务的MathSolver来评估表达式：

现在来看如何使用httptest库在不启动服务端的情况下测试这段代码。代码位于第15章的GitHub代码库的solver/remote_solver_test.go中的TestRemoteSolver_Resolve函数中，以下是要点。首先，我们希望保障传递给函数的数据到达服务端。因此，在测试函数中，我们定义了一个名为info的类型来保存输入和输出，以及一个名为io的变量，该变量被赋予当前的输入和输出值：

接着伪装启动一个远程服务端，使用它来配置RemoteSolver的实例：

httptest.NewServer函数在随机未使用的端口上启动一个HTTP服务端。我们需要提供一个http.Handler实现在处理请求。因其是服务端，必须在测试完成后关闭。http.Handler实例的URL通过server实例的URL字段指定，以及有一个预配置的http.Client与测试服务器之间进行通讯。我们将它们传递给RemoteSolver。

函数剩下的部分与其它表格测试并无分别：

需要注意变量io由两个不同的闭包捕获：一个用于桩服务器，一个用于运行各条测试。我们在一个闭包中写入、在另一个闭包中读取。在生产代码里这种做法不好，但在单个函数的测试代码完全成立。

集成测试和构建标签

虽然httptest提供了一种不依赖外部服务的测试方式，但还是应该编写集成测试、连接其它服务的自动化测试。这些可以验证我们对服务API的理解是正确的。挑战是如何对自动化测试进行分组，只应在存在支撑环境时才运行集成测试。同时，集成测试一般比单元测试慢，所以不要频繁测试。

在Go语言工具中，我们讲到了构建标签，由Go编译器用于控制文件何时编译。虽然它们主要用于让开发者编写针对指定操作系统、CPU或Go版本的代码，但也可以利用其能力指定自定义标签来控制何时编译及运行测试。

让我们尝试使用我们的数学求解项目。通过docker pull jonbodner/math-server使用Docker下载一个服务实现，然后在本地使用docker run -p 8080:8080 jonbodner/math-server命令将服务运行在8080端口上。

注： 如果读者没有安装Docker，或者希望自行构建代码，可以在GitHub上找到相关代码。

我们需要编写一个集成测试，以确保我们的Resolve方法正确地与数学服务器进行通信。第15章的GitHub代码库中的sample_code/solver/remote_solver_integration_test.go文件中的TestRemoteSolver_ResolveIntegration函数包含了一个完整的测试。这个测试看起来和我们之前编写的表格测试一样。要注意的是文件的第一行，包声明之前由一行分隔，如下所示：

与我们所编写的其它测试一同运行集成测试，使用：

使用-short标记

另一种分组测试的方法是使用go test命令加-short标记。如果希望跳过执行时间较长的测试，可以通过在测试函数开头添加以下代码来标记出慢速测试：

if testing.Short() { t.Skip("skipping test in short mode.") }

1 2 3

if testing.Short() {         t.Skip("skipping test in short mode.")     }

在只希望运行短测试时，对go test传递-short标记。

使用-short标记运行短测试时需要注意一些问题。如果使用该标记，测试仅分为两个级别：短测试和所有测试。通过使用构建标签，可以对集成测试分组，指定它们运行需要使用的服务。另一个不使用-short标记来表示集成测试的理由是逻辑上的。构建标签表示依赖关系，而-short标记只是表示不希望运行耗时很长的测试。这是不同的概念。最后，我认为-short标记不直观。始终应该运行短测试。更合理的做法是用一个标记来包含长时间运行的测试，而不是排除它们。

通过竞态检查器发现并发问题

虽然Go内置支持并发，还是会出现bug。很容易在不获取锁而误在两个不同的协程中引用同一变量。在计算机科学中这称为数据竞争（data race）。为有助找到这类bug，Go中内置了一个竞态检查器。它并不保证能找到代码中的每个数据竞争，如若找到，应对其添加适当的锁。

我们来看第15章的GitHub代码库中的简单示例sample_code/race/race.go ：

这段代码启动了5个协程，每个协程都对共享变量counter进行1000次更新，然后返回结果。预期结果为5000，那么我们就用sample_code/race/race_test.go中的单元测试进行验证吧：

如果多次运行go test，会发现有时会通过，但大多数时候会得到这样的错误消息：

问题在于代码中存在数据竞争。在简单的程序中，原因很明显：多个协程尝试同时更新counter而部分更新丢失了。在更复杂的程序中，这些竞争会更难发现。我们来看竞态检查器有什么功能。对go test使用-race标记来进行启用：

跟踪信息清晰地表明counter++行是问题的根源。

警告： 有些人试图通过在代码中插入sleep来修复竞态条件，以将多个协程访问的变量的访问岔开。这种做法很糟糕。这样做可能在某些情况下消除问题，但代码仍然是错误的，在一些情况下会失败。

还可以在构建程序时使用-race标记。这会创建一个包含竞态检查器的二进制文件，并将它找到的所有竞态报告到控制台。这样在没有测试的代码中可找到数据竞争。

竞态检查器这么有用，为什么不在所有测试和生产环境中始终启用它呢？启用-race的二进制运行速度约比正常二进制慢10倍。对于需要几分钟才能运行的大型测试套件，这不什么是问题，但对于运行时间仅为一秒的测试套件来说，10倍慢的速度会降低生产效率。

模糊测试

每个开发人员最终都会学到的一项最重要的教训是所有数据都不可信。无论数据格式规范得多好，最终都将得处理与期望所不匹配的输入。这并不仅仅因恶意所致。数据在传输过程、存储甚至在内存中都可能受到损坏。处理数据的程序可能存在bug，而数据格式规范总会有一些边界情况，不同的开发人员的解释方式也会不同。

即使开发人员编写了良好的单元测试，也不可能考虑到所有情况。我们已经了解到，即使具有100%的单元测试覆盖率，也不能保证代码没有bug。需要用生成的数据来补充单元测试，这些数据可能会以预料外的方式破坏程序。这就用到了模糊测试。

模糊测试（Fuzzing）是一种生成随机数据并将其提交给代码以查看它是否正确处理意外输入的技术。开发人员可以提供一个种子语料库或一组已知的好数据，模糊测试器使用这些数据来生成有问题的输入。我们来看如何使用Go测试工具中的模糊测试来发现额外的测试用例。

假设我们正在编写一个处理数据文件的程序。示例代码位于GitHub上。我们发送了一个字符串列表，但希望高效地分配内存，因此文件中的字符串数以第一行发送，其余行为文本行。以下是处理该数据的示例函数：

我们使用bufio.Scanner逐行从io.Reader中读取。如果没有供读取的数据，返回一个错误。然后读取第一行并尝试将其转化为命名为的整型count。如转化失败，返回错误。接着，为字符串切片分配内存并从Scanner中读取count行。如果行数不足，返回错误。一切正常的话，返回所读取的行数。

已编写了验证该代码的单元测试：