1. Go 测试代码的一般逻辑

众所周知，Go 的测试函数就是一个普通的 Go 函数，Go 仅对测试函数的函数名和函数原型有特定要求，除此之外，Go 对在测试函数TestXxx或其子测试函数(subtest)中如何编写测试逻辑并没有显式的约束。对测试失败与否的判断在于测试代码逻辑是否进入了包含Error/Errorf、Fatal/Fatalf等方法调用的代码分支。一旦进入这些分支，即代表该测试失败。不同的是Error/Errorf并不会立刻终止当前 goroutine 的执行，还会继续执行该 goroutine 后续的测试，而Fatal/Fatalf则会立刻停止当前 goroutine 的测试执行。

下面的测试代码示例改编自$GOROOT/src/strings/compare_test.go：

// non_table_driven_strings_test.go 
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    var a, b string
    var i int
    a, b = "", ""
    i = 0
    cmp := strings.Compare(a, b)
    if cmp != i {
        t.Errorf(`want %v, but Compare(%q, %q) = %v`, i, a, b, cmp)
    }
    a, b = "a", ""
    i = 1
    cmp = strings.Compare(a, b)
    if cmp != i {
        t.Errorf(`want %v, but Compare(%q, %q) = %v`, i, a, b, cmp)
    }
    a, b = "", "a"
    i = -1
    cmp = strings.Compare(a, b)
    if cmp != i {
        t.Errorf(`want %v, but Compare(%q, %q) = %v`, i, a, b, cmp)
    }
}

2. 表驱动的测试实践

Go 测试代码的逻辑十分简单，约束也甚少。但我们发现：上面仅有三组预置输入数据的示例的测试代码已显得十分冗长，如果为测试预置的数据组数增多，测试函数本身就将变得十分庞大。并且，我们看到上述示例的测试逻辑中存在很多重复的代码，显得十分繁琐。我们来尝试对上述示例做一些改进：

// table_driven_strings_test.go 
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    compareTests := []struct {
        a, b string
        i    int
    }{
        {"", "", 0},
        {"a", "", 1},
        {"", "a", -1},
    }
    for _, tt := range compareTests {
        cmp := strings.Compare(tt.a, tt.b)
        if cmp != tt.i {
            t.Errorf(`want %v, but Compare(%q, %q) = %v`, tt.i, tt.a, tt.b, cmp)
        }
    }
}

在上面这个改进的示例中，我们将之前示例中重复的测试逻辑“合并”为一个，并将预置的输入数据放入一个自定义结构体类型的切片中。这个示例的长度看似并没有比之前的实例缩减多少，但是它却是一个“可扩展”的测试设计。如果我们增加输入测试数据的组数，就像下面这样：

// table_driven_strings_more_cases_test.go 
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    compareTests := []struct {
        a, b string
        i    int
    }{
        {"", "", 0},
        {"a", "", 1},
        {"", "a", -1},
        {"abc", "abc", 0},
        {"ab", "abc", -1},
        {"abc", "ab", 1},
        {"x", "ab", 1},
        {"ab", "x", -1},
        {"x", "a", 1},
        {"b", "x", -1},
        // test runtime·memeq's chunked implementation
        {"abcdefgh", "abcdefgh", 0},
        {"abcdefghi", "abcdefghi", 0},
        {"abcdefghi", "abcdefghj", -1},
    }
    for _, tt := range compareTests {
        cmp := strings.Compare(tt.a, tt.b)
        if cmp != tt.i {
            t.Errorf(`want %v, but Compare(%q, %q) = %v`, tt.i, tt.a, tt.b, cmp)
        }
    }
}

大家可以看到：我们无需改动后面的测试逻辑，只需在切片中增加数据条目即可。在这种测试设计中，这个自定义结构体类型的切片(上述示例中的compareTests)就是一个表，而基于这个数据表的测试设计和实现则被称为“表驱动的测试”。

3. 表驱动测试的优点

表驱动测试有着诸多优点。

简单与紧凑
数据即测试
结合子测试(subtest)后，可单独运行某个数据项的测试

我们将表驱动测试与子测试结合来改造一下上面的strings_test示例：

// table_driven_strings_with_subtest_test.go
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    compareTests := []struct {
        name, a, b string
        i          int
    }{
        {`compareTwoEmptyString`, "", "", 0},
        {`compareSecondParamIsEmpty`, "a", "", 1},
        {`compareFirstParamIsEmpty`, "", "a", -1},
    }
    for _, tt := range compareTests {
        t.Run(tt.name, func(t *testing.T) {
            cmp := strings.Compare(tt.a, tt.b)
            if cmp != tt.i {
                t.Errorf(`want %v, but Compare(%q, %q) = %v`, tt.i, tt.a, tt.b, cmp)
            }
        })
    }
}

在示例中，我们将测试结果的判定逻辑放入一个单独的子测试中，这样我们可以单独执行表中某项数据的测试，比如：我们单独执行表中第一个数据项对应的测试：

$go test -v  -run /TwoEmptyString table_driven_strings_with_subtest_test.go
=== RUN   TestCompare
=== RUN   TestCompare/compareTwoEmptyString
--- PASS: TestCompare (0.00s)
    --- PASS: TestCompare/compareTwoEmptyString (0.00s)
PASS
ok      command-line-arguments    0.005s

4. 表驱动测试实践过程中的注意事项

1) 表的实现方式

在上面的示例中，测试中使用的表是用自定义结构体的切片实现的，表也可以使用基于自定义结构体的其他集合类型来实现，比如：map。我们将上面的例子改造为采用map来实现测试数据表：

// table_driven_strings_with_map_test.go     
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    compareTests := map[string]struct {
        a, b string
        i    int
    }{
        `compareTwoEmptyString`:     {"", "", 0},
        `compareSecondParamIsEmpty`: {"a", "", 1},
        `compareFirstParamIsEmpty`:  {"", "a", -1},
    }
    for name, tt := range compareTests {
        t.Run(name, func(t *testing.T) {
            cmp := strings.Compare(tt.a, tt.b)
            if cmp != tt.i {
                t.Errorf(`want %v, but Compare(%q, %q) = %v`, tt.i, tt.a, tt.b, cmp)
            }
        })
    }
}

使用map作为数据表时要注意：表内数据项的测试先后顺序是不确定的。

第一次：
$go test -v table_driven_strings_with_map_test.go
=== RUN   TestCompare
=== RUN   TestCompare/compareTwoEmptyString
=== RUN   TestCompare/compareSecondParamIsEmpty
=== RUN   TestCompare/compareFirstParamIsEmpty
--- PASS: TestCompare (0.00s)
    --- PASS: TestCompare/compareTwoEmptyString (0.00s)
    --- PASS: TestCompare/compareSecondParamIsEmpty (0.00s)
    --- PASS: TestCompare/compareFirstParamIsEmpty (0.00s)
PASS
ok      command-line-arguments    0.005s
第二次：
$go test -v table_driven_strings_with_map_test.go
=== RUN   TestCompare
=== RUN   TestCompare/compareFirstParamIsEmpty
=== RUN   TestCompare/compareTwoEmptyString
=== RUN   TestCompare/compareSecondParamIsEmpty
--- PASS: TestCompare (0.00s)
    --- PASS: TestCompare/compareFirstParamIsEmpty (0.00s)
    --- PASS: TestCompare/compareTwoEmptyString (0.00s)
    --- PASS: TestCompare/compareSecondParamIsEmpty (0.00s)
PASS
ok      command-line-arguments    0.005s

2) 测试失败时的数据项的定位

我们需要在测试失败的输出结果中输出数据表项的唯一标识。

一个最简单的方法就是通过输出数据表项在数据表中的偏移量来辅助定位“凶手”：

// table_driven_strings_by_offset_test.go 
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    compareTests := []struct {
        a, b string
        i    int
    }{
        {"", "", 7},
        {"a", "", 6},
        {"", "a", -1},
    }
    for i, tt := range compareTests {
        cmp := strings.Compare(tt.a, tt.b)
        if cmp != tt.i {
            t.Errorf(`[table offset: %v] want %v, but Compare(%q, %q) = %v`, i+1, tt.i, tt.a, tt.b, cmp)
        }
    }
}

运行该示例：

$go test -v table_driven_strings_by_offset_test.go
=== RUN   TestCompare
    TestCompare: table_driven_strings_by_offset_test.go:21: [table offset: 1] want 7, but Compare("", "") = 0
    TestCompare: table_driven_strings_by_offset_test.go:21: [table offset: 2] want 6, but Compare("a", "") = 1
--- FAIL: TestCompare (0.00s)
FAIL
FAIL    command-line-arguments    0.005s
FAIL

另外一个更直观的方式是使用名字来区分不同数据项：

// table_driven_strings_by_name_test.go 
package string_test
import (
    "strings"
    "testing"
)
func TestCompare(t *testing.T) {
    compareTests := []struct {
        name, a, b string
        i          int
    }{
        {"compareTwoEmptyString", "", "", 7},
        {"compareSecondStringEmpty", "a", "", 6},
        {"compareFirstStringEmpty", "", "a", -1},
    }
    for _, tt := range compareTests {
        cmp := strings.Compare(tt.a, tt.b)
        if cmp != tt.i {
            t.Errorf(`[%s] want %v, but Compare(%q, %q) = %v`, tt.name, tt.i, tt.a, tt.b, cmp)
        }
    }
}

运行该示例：

$go test -v table_driven_strings_by_name_test.go
=== RUN   TestCompare
    TestCompare: table_driven_strings_by_name_test.go:21: [compareTwoEmptyString] want 7, but Compare("", "") = 0
    TestCompare: table_driven_strings_by_name_test.go:21: [compareSecondStringEmpty] want 6, but Compare("a", "") = 1
--- FAIL: TestCompare (0.00s)
FAIL
FAIL    command-line-arguments    0.005s
FAIL

3) Errorf 还是 Fatalf

关于是选择Errorf还是Fatalf并没有固定标准，一般而言，如果一个数据项导致的测试失败不会对后面的数据项的测试结果造成影响，那么推荐Errorf，这样可以通过一次测试执行，看到所有导致测试失败的数据表项；否则，如果数据项导致的测试失败会直接影响到后续数据项的测试结果，那么可以使用Fatalf让测试尽快结束，因为继续执行后面数据项驱动的测试的意义已经不大了。

改善Go语言编程质量的50个有效实践

34 Go 单元测试惯例：表驱动