go的单元测试

进行单元测试的最重要原因是保证自己代码的健壮性。
一个接口可能用API测试没有问题，能够实现功能，或者像某些非接口任务，比如定时任务或者异步的任务，简单的通过APIFOX调用可能很难发现问题，但是这时候走一遍单测，便能更进一步的提升代码质量，发现问题。
开发人员在提测前，最好是自己自测一下！
下面简单介绍一下单元测试~~~
每个测试函数必须导入testing包。测试函数有如下的签名：

funcTestName(t *testing.T){}

测试函数的名字必须以Test开头，可选的后缀名必须以大写字母开头：

funcTestSin(t *testing.T){}funcTestCos(t *testing.T){}funcTestLog(t *testing.T){}

其中t参数用于报告测试失败和附加的日志信息。让我们定义一个实例包gopl.io/ch11/word1，其中只有一个函数IsPalindrome用于检查一个字符串是否从前向后和从后向前读都是一样的。（下面这个实现对于一个字符串是否是回文字符串前后重复测试了两次；我们稍后会再讨论这个问题。）

package word

funcIsPalindrome(s string)bool{for i :=range s {if s[i]!= s[len(s)-1-i]{returnfalse}}returntrue}

在相同的目录下，word_test.go测试文件中包含了TestPalindrome和TestNonPalindrome两个测试函数。每一个都是测试IsPalindrome是否给出正确的结果，并使用t.Error报告失败信息：

package word

import"testing"funcTestPalindrome(t *testing.T){if!IsPalindrome("detartrated"){
        t.Error(`IsPalindrome("detartrated") = false`)}if!IsPalindrome("kayak"){
        t.Error(`IsPalindrome("kayak") = false`)}}funcTestNonPalindrome(t *testing.T){ifIsPalindrome("palindrome"){
        t.Error(`IsPalindrome("palindrome") = true`)}}

go test命令如果没有参数指定包那么将默认采用当前目录对应的包（和go build命令一样）。我们可以用下面的命令构建和运行测试。

$ cd $GOPATH/src/gopl.io/ch11/word1
$ go test
ok   gopl.io/ch11/word1  0.008s

结果还比较满意，我们运行了这个程序， 不过没有提前退出是因为还没有遇到BUG报告。不过一个法国名为“Noelle Eve Elleon”的用户会抱怨IsPalindrome函数不能识别“été”。另外一个来自美国中部用户的抱怨则是不能识别“A man, a plan, a canal: Panama.”。执行特殊和小的BUG报告为我们提供了新的更自然的测试用例。

funcTestFrenchPalindrome(t *testing.T){if!IsPalindrome("été"){
        t.Error(`IsPalindrome("été") = false`)}}funcTestCanalPalindrome(t *testing.T){
    input :="A man, a plan, a canal: Panama"if!IsPalindrome(input){
        t.Errorf(`IsPalindrome(%q) = false`, input)}}

为了避免两次输入较长的字符串，我们使用了提供了有类似Printf格式化功能的 Errorf函数来汇报错误结果。

当添加了这两个测试用例之后，go test返回了测试失败的信息。

$ go test
--- FAIL: TestFrenchPalindrome (0.00s)
    word_test.go:28:IsPalindrome("été")=false--- FAIL: TestCanalPalindrome (0.00s)
    word_test.go:35:IsPalindrome("A man, a plan, a canal: Panama")=false
FAIL
FAIL    gopl.io/ch11/word1  0.014s

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

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

参数-v可用于打印每个测试函数的名字和运行时间：

$ go test -v
=== RUN TestPalindrome
--- PASS: TestPalindrome (0.00s)=== RUN TestNonPalindrome
--- PASS: TestNonPalindrome (0.00s)=== RUN TestFrenchPalindrome
--- FAIL: TestFrenchPalindrome (0.00s)
    word_test.go:28:IsPalindrome("été")=false=== RUN TestCanalPalindrome
--- FAIL: TestCanalPalindrome (0.00s)
    word_test.go:35:IsPalindrome("A man, a plan, a canal: Panama")=false
FAIL
exit status 1
FAIL    gopl.io/ch11/word1  0.017s

参数-run对应一个正则表达式，只有测试函数名被它正确匹配的测试函数才会被go test测试命令运行：

$ go test -v -run="French|Canal"=== RUN TestFrenchPalindrome
--- FAIL: TestFrenchPalindrome (0.00s)
    word_test.go:28:IsPalindrome("été")=false=== RUN TestCanalPalindrome
--- FAIL: TestCanalPalindrome (0.00s)
    word_test.go:35:IsPalindrome("A man, a plan, a canal: Panama")=false
FAIL
exit status 1
FAIL    gopl.io/ch11/word1  0.014s

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

我们现在的任务就是修复这些错误。简要分析后发现第一个BUG的原因是我们采用了 byte而不是rune序列，所以像“été”中的é等非ASCII字符不能正确处理。第二个BUG是因为没有忽略空格和字母的大小写导致的。

针对上述两个BUG，我们仔细重写了函数：

gopl.io/ch11/word2

package word

import"unicode"funcIsPalindrome(s string)bool{var letters []runefor_, r :=range s {if unicode.IsLetter(r){
            letters =append(letters, unicode.ToLower(r))}}for i :=range letters {if letters[i]!= letters[len(letters)-1-i]{returnfalse}}returntrue}

同时我们也将之前的所有测试数据合并到了一个测试中的表格中。

funcTestIsPalindrome(t *testing.T){var tests =[]struct{
        input string
        want  bool}{{"",true},{"a",true},{"aa",true},{"ab",false},{"kayak",true},{"detartrated",true},{"A man, a plan, a canal: Panama",true},{"Evil I did dwell; lewd did I live.",true},{"Able was I ere I saw Elba",true},{"été",true},{"Et se resservir, ivresse reste.",true},{"palindrome",false},{"desserts",false},}for_, test :=range tests {if got :=IsPalindrome(test.input); got != test.want {
            t.Errorf("IsPalindrome(%q) = %v", test.input, got)}}}

现在我们的新测试都通过了：

$ go test gopl.io/ch11/word2
ok      gopl.io/ch11/word2      0.015s

这种表格驱动的测试在Go语言中很常见。我们可以很容易地向表格添加新的测试数据，并且后面的测试逻辑也没有冗余，这样我们可以有更多的精力去完善错误信息。

失败测试的输出并不包括调用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的长度，输出一个相关部分的简明总结即可。测试的作者应该要努力帮助程序员诊断测试失败的原因。