Go 测试：表驱动测试与基准测试

为什么需要掌握这两种测试方法

编写测试是保证代码质量的基础工作，但测试代码本身也需要精心设计。当你面对一个函数有多种输入情况和预期输出时，如果为每种情况单独写一个测试函数，代码会变得臃肿且难以维护。Go 语言社区总结出两种被广泛采用的测试模式：表驱动测试和基准测试。前者让多用例测试变得简洁优雅，后者帮助你量化代码性能。本文将手把手教你掌握这两种技术。

表驱动测试：让多用例测试井然有序

什么是表驱动测试

表驱动测试的核心思想是将测试用例组织成表格结构，每个用例包含输入参数和预期结果。测试函数通过遍历这个表格，依次执行断言。这种模式特别适合测试逻辑相同但输入输出各异的场景。

编写你的第一个表驱动测试

假设你正在编写一个计算器，需要测试加法函数。传统的做法可能是这样的：

func TestAddBasic(t *testing.T) {
    if Add(1, 2) != 3 {
        t.Error("1 + 2 should be 3")
    }
    if Add(-1, 1) != 0 {
        t.Error("-1 + 1 should be 0")
    }
    if Add(100, 200) != 300 {
        t.Error("100 + 200 should be 300")
    }
}

这种写法虽然能工作，但存在明显问题：每个断言失败都会终止当前函数，后续用例无法继续执行。表驱动测试完美解决了这个痛点：

func TestAdd(t *testing.T) {
    // 定义测试用例表格
    tests := []struct {
        name     string
        a, b     int
        expected int
    }{
        {"正数相加", 1, 2, 3},
        {"负数相加", -1, 1, 0},
        {"大数相加", 100, 200, 300},
        {"零相加", 0, 5, 5},
        {"负负得正", -5, -3, -8},
    }

    // 遍历表格执行每个用例
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Add(tt.a, tt.b)
            if got != tt.expected {
                t.Errorf("Add(%d, %d) = %d, want %d", tt.a, tt.b, got, tt.expected)
            }
        })
    }
}

运行这个测试，你会看到每个用例都作为子测试独立执行，输出清晰展示了每个测试用例的执行情况。

让表驱动测试更强大：测试错误处理

实际开发中，函数不仅需要验证正确返回，还需要测试错误情况。以下示例展示了如何测试一个解析函数：

func TestParseNumber(t *testing.T) {
    tests := []struct {
        name        string
        input       string
        expectedVal int
        expectError bool
    }{
        {"有效正整数", "42", 42, false},
        {"有效负整数", "-10", -10, false},
        {"零值", "0", 0, false},
        {"空白字符串", "", 0, true},
        {"非数字字符串", "abc", 0, true},
        {"带空格的数字", "  20  ", 20, false},
        {"浮点数", "3.14", 0, true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := ParseNumber(tt.input)
            if tt.expectError {
                if err == nil {
                    t.Errorf("ParseNumber(%q) expected error, got nil", tt.input)
                }
            } else {
                if err != nil {
                    t.Errorf("ParseNumber(%q) unexpected error: %v", tt.input, err)
                }
                if got != tt.expectedVal {
                    t.Errorf("ParseNumber(%q) = %d, want %d", tt.input, got, tt.expectedVal)
                }
            }
        })
    }
}

这种结构让你能够在单个测试函数中覆盖正常流程和异常流程，代码组织清晰，维护成本低。

表格驱动测试的适用场景

判断是否应该使用表驱动测试，可以参考以下标准：

当你的测试用例需要频繁添加或修改时，表驱动测试的优势会更加明显。你只需要在表格中增加一行，无需改动测试函数结构。

基准测试：量化代码性能

基准测试基础

Go 标准库提供了 testing.B 类型用于编写基准测试。与普通测试不同，基准测试会多次运行以获取稳定的性能数据。运行基准测试需要使用 go test -bench 命令。

编写第一个基准测试

假设你需要评估 Add 函数的性能：

func BenchmarkAdd(b *testing.B) {
    // b.N 是测试框架自动调整的迭代次数
    for i := 0; i < b.N; i++ {
        Add(1, 2)
    }
}

运行基准测试：

go test -bench=.

输出结果类似于：

BenchmarkAdd-8    1000000000           0.212 ns/op

最后一列 0.212 ns/op 表示每次操作耗时 0.212 纳秒，这个数值越低代表性能越好。

避免编译器优化导致的虚假数据

基准测试中最常见的陷阱是编译器优化。如果你的被测代码计算结果从未被使用，编译器可能直接跳过计算，导致测试结果毫无意义：

// 错误写法：结果未被使用，可能被优化
func BenchmarkBad(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Add(1, 2)
    }
}

// 正确写法：使用 runtime.KeepAlive 确保结果被消费
func BenchmarkGood(b *testing.B) {
    b.ReportAllocs()
    var result int
    for i := 0; i < b.N; i++ {
        result = Add(1, 2)
        runtime.KeepAlive(result)
    }
}

使用 b.ReportAllocs() 可以同时监控内存分配情况，这在评估算法内存效率时非常有用。

比较不同实现的性能

当你需要比较两种算法的优劣时，基准测试是最好的决策依据。以下示例比较了两种字符串拼接方式：

// 方式一：使用 += 运算符
func BenchmarkConcatPlus(b *testing.B) {
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        var s string
        for j := 0; j < 100; j++ {
            s += "a"
        }
        _ = s
    }
}

// 方式二：使用 strings.Builder
func BenchmarkConcatBuilder(b *testing.B) {
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        var builder strings.Builder
        for j := 0; j < 100; j++ {
            builder.WriteString("a")
        }
        _ = builder.String()
    }
}

运行测试并比较结果：

go test -bench=. -benchmem

输出会清晰显示哪种方式在时间和空间上更高效。

基准测试的运行参数

Go 的基准测试支持多种参数来满足不同需求：

默认情况下，每次基准测试至少运行 1 秒。如果需要更稳定的数据，可以增加运行时间：

go test -bench=. -benchtime=5s

进阶技巧：组合两种测试模式

在基准测试中使用表驱动用例

有时你需要在基准测试中评估函数在不同输入下的表现，这可以通过组合表驱动模式和基准测试来实现：

// 定义测试用例表格
var benchmarkCases = []struct {
    name  string
    input string
}{
    {"短字符串", "hello"},
    {"中等长度", strings.Repeat("a", 100)},
    {"长字符串", strings.Repeat("a", 10000)},
}

func BenchmarkReverse(b *testing.B) {
    for _, tc := range benchmarkCases {
        b.Run(tc.name, func(b *testing.B) {
            b.ReportAllocs()
            input := tc.input // 在闭包中捕获输入
            for i := 0; i < b.N; i++ {
                ReverseString(input)
            }
        })
    }
}

这种方式让你能够在单次测试运行中获取多个场景的性能数据，便于横向比较。

并行基准测试

如果你的代码在并发场景下工作，可以测试多线程性能：

func BenchmarkParallel(b *testing.B) {
    b.ReportAllocs()
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            // 并行执行的代码
            Add(1, 2)
        }
    })
}

运行并行基准测试时，-cpu 参数特别有用：

go test -bench=Parallel -benchmem -cpu=1,2,4,8

这会分别测试 1、2、4、8 个 CPU 核心下的性能表现，帮助你了解代码的可扩展性。

常见陷阱与解决方案

陷阱一：测试顺序依赖

表驱动测试中，如果用例之间存在共享状态，可能导致测试相互干扰。始终确保每个用例使用独立的输入数据，避免修改全局变量或共享资源。

陷阱二：基准测试时间过短

如果测试时间少于 1 秒，测量结果可能不够精确。使用 -benchtime 参数增加测试时长，特别是对于执行速度很快的函数。

陷阱三：忽略边界条件

测试用例设计不完整会遗漏潜在 bug。重点关注边界情况，包括空值、零值、最大最小值、特殊字符等。

陷阱四：误用 t.Fatal 在子测试中

在 t.Run 的回调函数中使用 t.Fatal 会终止整个测试，而不仅仅是当前子测试。在子测试中始终使用 t.Errorf 报告错误，让其他用例继续执行。

最佳实践清单

编写高质量测试时，遵循以下原则可以显著提升代码可靠性和可维护性：

1. 测试用例命名要有意义：t.Run 的名称应该清楚描述测试场景，方便定位问题
2. 保持表格简洁：如果表格过大，考虑拆分为多个测试函数
3. 同时测试正常流程和异常流程：错误处理同样是代码的重要部分
4. 基准测试需要预热：首次运行可能有 JIT 编译等开销，可使用 b.ResetTimer() 重置计时器
5. 版本控制追踪性能变化：将基准测试结果纳入 CI/CD 流程，及时发现性能退化

掌握表驱动测试和基准测试后，你会发现测试工作变得系统化和可量化。这两种技术不仅提升了代码质量，也让性能优化有据可依。