mirror of
https://github.com/gopl-zh/gopl-zh.github.com.git
synced 2024-11-05 05:53:45 +00:00
230 lines
8.5 KiB
Markdown
230 lines
8.5 KiB
Markdown
## 11.2. 测试函数
|
||
|
||
每个测试函数必须导入testing包。测试函数有如下的签名：
|
||
|
||
```Go
|
||
func TestName(t *testing.T) {
|
||
// ...
|
||
}
|
||
```
|
||
|
||
测试函数的名字必须以Test开头，可选的后缀名必须以大写字母开头：
|
||
|
||
```Go
|
||
func TestSin(t *testing.T) { /* ... */ }
|
||
func TestCos(t *testing.T) { /* ... */ }
|
||
func TestLog(t *testing.T) { /* ... */ }
|
||
```
|
||
|
||
其中t参数用于报告测试失败和附加的日志信息。让我们定义一个实例包gopl.io/ch11/word1，其中只有一个函数IsPalindrome用于检查一个字符串是否从前向后和从后向前读都是一样的。（下面这个实现对于一个字符串是否是回文字符串前后重复测试了两次；我们稍后会再讨论这个问题。）
|
||
|
||
<u><i>gopl.io/ch11/word1</i></u>
|
||
```Go
|
||
// Package word provides utilities for word games.
|
||
package word
|
||
|
||
// IsPalindrome reports whether s reads the same forward and backward.
|
||
// (Our first attempt.)
|
||
func IsPalindrome(s string) bool {
|
||
for i := range s {
|
||
if s[i] != s[len(s)-1-i] {
|
||
return false
|
||
}
|
||
}
|
||
return true
|
||
}
|
||
```
|
||
|
||
在相同的目录下，word_test.go测试文件中包含了TestPalindrome和TestNonPalindrome两个测试函数。每一个都是测试IsPalindrome是否给出正确的结果，并使用t.Error报告失败信息：
|
||
|
||
```Go
|
||
package word
|
||
|
||
import "testing"
|
||
|
||
func TestPalindrome(t *testing.T) {
|
||
if !IsPalindrome("detartrated") {
|
||
t.Error(`IsPalindrome("detartrated") = false`)
|
||
}
|
||
if !IsPalindrome("kayak") {
|
||
t.Error(`IsPalindrome("kayak") = false`)
|
||
}
|
||
}
|
||
|
||
func TestNonPalindrome(t *testing.T) {
|
||
if IsPalindrome("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报告为我们提供了新的更自然的测试用例。
|
||
|
||
```Go
|
||
func TestFrenchPalindrome(t *testing.T) {
|
||
if !IsPalindrome("été") {
|
||
t.Error(`IsPalindrome("été") = false`)
|
||
}
|
||
}
|
||
|
||
func TestCanalPalindrome(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，我们仔细重写了函数：
|
||
|
||
<u><i>gopl.io/ch11/word2</i></u>
|
||
```Go
|
||
// Package word provides utilities for word games.
|
||
package word
|
||
|
||
import "unicode"
|
||
|
||
// IsPalindrome reports whether s reads the same forward and backward.
|
||
// Letter case is ignored, as are non-letters.
|
||
func IsPalindrome(s string) bool {
|
||
var letters []rune
|
||
for _, 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] {
|
||
return false
|
||
}
|
||
}
|
||
return true
|
||
}
|
||
```
|
||
|
||
同时我们也将之前的所有测试数据合并到了一个测试中的表格中。
|
||
|
||
```Go
|
||
func TestIsPalindrome(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}, // non-palindrome
|
||
{"desserts", false}, // semi-palindrome
|
||
}
|
||
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的长度，输出一个相关部分的简明总结即可。测试的作者应该要努力帮助程序员诊断测试失败的原因。
|
||
|
||
**练习 11.1:** 为4.3节中的charcount程序编写测试。
|
||
|
||
**练习 11.2:** 为（§6.5）的IntSet编写一组测试，用于检查每个操作后的行为和基于内置map的集合等价，后面练习11.7将会用到。
|
||
|
||
|
||
{% include "./ch11-02-1.md" %}
|
||
|
||
{% include "./ch11-02-2.md" %}
|
||
|
||
{% include "./ch11-02-3.md" %}
|
||
|
||
{% include "./ch11-02-4.md" %}
|
||
|
||
{% include "./ch11-02-5.md" %}
|
||
|
||
{% include "./ch11-02-6.md" %}
|