测试

现在的程序已经远比Wilkes时代的更大也更复杂，也有许多技术可以让软件的复杂性可得到
控制。其中有两种技术在实践中证明是比较有效的。第一种是代码在被正式部署前需要进行
代码评审。第二种则是测试

我们说测试的时候一般是指自动化测试，也就是写一些小的程序用来检测被测试代码（产品
代码）的行为和预期的一样，这些通常都是精心设计的执行某些特定的功能或者是通过随机
性的输入要验证边界的处理。

软件测试是一个巨大的领域。测试的任务可能已经占据了一些程序员的部分时间和另一些程
序员的全部时间。和软件测试技术相关的图书或博客文章有成千上万之多。对于每一种主流
的编程语言，都会有一打的用于测试的软件包，同时也有大量的测试相关的理论，而且每种
都吸引了大量技术先驱和追随者。这些都足以说服那些想要编写有效测试的程序员重新学习
一套全新的技能。

Go语言的测试技术是相对低级的。它依赖一个go test测试命令和一组按照约定方式编写的测
试函数，测试命令可以运行这些测试函数。编写相对轻量级的纯测试代码是有效的，而且它
很容易延伸到基准测试和示例文档。

在实践中，编写测试代码和编写程序本身并没有多大区别。我们编写的每一个函数也是针对
每个具体的任务。我们必须小心处理边界条件，思考合适的数据结构，推断合适的输入应该
产生什么样的结果输出。编程测试代码和编写普通的Go代码过程是类似的；它并不需要学习
新的符号、规则和工具。

go test

go test命令是一个按照一定的约定和组织的测试代码的驱动程序。在包目录内，所有以
_test.go为后缀名的源文件并不是go build构建包的一部分，它们是go test测试的一部分。
在*_test.go文件中，有三种类型的函数：测试函数、基准测试函数、示例函数。一个测试函
数是以Test为函数名前缀的函数，用于测试程序的一些逻辑行为是否正确；go test命令会调用
这些测试函数并报告测试结果是PASS或FAIL。基准测试函数是以Benchmark为函数名前缀的
函数，它们用于衡量一些函数的性能；go test命令会多次运行基准函数以计算一个平均的执
行时间。

go test命令会遍历所有的*_test.go文件中符合上述命名规则的函数，然后生成一个临时的
main包用于调用相应的测试函数，然后构建并运行、报告测试结果，最后清理测试中生成的
临时文件。

测试函数

每个测试函数必须导入testing包。测试函数有如下的签名：
func TestName(t *testing.T) {
// ...
}
测试函数的名字必须以Test开头，可选的后缀名必须以大写字母开头：

func TestSin(t testing.T) { / ... */ }
func TestCos(t testing.T) { / ... */ }
func TestLog(t testing.T) { / ... */ }
其中t参数用于报告测试失败和附加的日志信息。

go test 命令如果没有参数指定包那么将默认采用当前目录对应的包（和 go build 命令一
样）。我们可以用下面的命令构建和运行测试。
$ cd $GOPATH/src/gopl.io/ch11/word1
$ go test
ok gopl.io/ch11/word1 0.008s

先编写测试用例并观察到测试用例触发了和用户报告的错误相同的描述是一个好的测试习
惯。只有这样，我们才能定位我们要真正解决的问题。

先写测试用例的另外的好处是，运行测试通常会比手工描述报告的处理更快，这让我们可以
进行快速地迭代。如果测试集有很多运行缓慢的测试，我们可以通过只选择运行某些特定的
测试来加快测试速度。

当然，一旦我们已经修复了失败的测试用例，在我们提交代码更新之前，我们应该以不带参
数的 go test 命令运行全部的测试用例，以确保修复失败测试的同时没有引入新的问题。

失败测试的输出并不包括调用t.Errorf时刻的堆栈调用信息。和其他编程语言或测试框架的
assert断言不同，t.Errorf调用也没有引起panic异常或停止测试的执行。即使表格中前面的数
据导致了测试的失败，表格后面的测试数据依然会运行测试，因此在一个测试中我们可能了
解多个失败的信息。

如果我们真的需要停止测试，或许是因为初始化失败或可能是早先的错误导致了后续错误等
原因，我们可以使用t.Fatal或t.Fatalf停止当前测试函数。它们必须在和测试函数同一个
goroutine内调用。

测试失败的信息一般的形式是“f(x) = y, want z”，其中f(x)解释了失败的操作和对应的输出，y
是实际的运行结果，z是期望的正确的结果。就像前面检查回文字符串的例子，实际的函数用
于f(x)部分。

如果显示x是表格驱动型测试中比较重要的部分，因为同一个断言可能对应不同的表格项执行多次。
要避免无用和冗余的信息。在测试类似IsPalindrome返回布尔类型的函数时，可以忽略并没有额外
信息的z部分。如果x、y或z是y的长度，输出一个相关部分的简明总结即可。测试的作者应该要努力
帮助程序员诊断测试失败的原因。