Golang表格驱动测试教程及实例演示

表格驱动测试在 Go 中为何推荐？因其结构清晰、易维护，提升可读性与扩展性。1. 集中管理输入输出；2. 提高代码可读性和维护效率；3. 方便扩展新用例。实现方式是定义结构体切片包含用例，遍历执行并比较结果，失败时通过 t.Errorf 输出详细错误信息。还可为用例添加 name 字段便于定位问题。适合参数和结果确定、多相似场景、无需复杂初始化的测试，尤其适用于纯函数类测试。

在写单元测试时，表格驱动测试（Table-Driven Test）是 Golang 中非常常见且推荐的方式。它通过一个结构化的数据表来定义多个测试用例，然后循环执行每个用例，让测试逻辑更清晰、更容易维护。

为什么用表格驱动测试？

Go 的测试风格推崇简洁和可读性，而表格驱动测试正好符合这个理念。相比为每个测试用例单独写一段代码，使用表格可以：

• 集中管理所有测试输入和预期输出；
• 提高测试代码的可读性和可维护性；
• 更容易扩展新用例。

如何写一个表格驱动测试？

假设我们有一个函数 Add(a, b int) int，返回两个整数的和。我们可以这样写测试：

func TestAdd(t *testing.T) {
    tests := []struct {
        a, b int
        want int
    }{
        {1, 2, 3},
        {0, 0, 0},
        {-1, 1, 0},
        {100, -50, 50},
    }

    for _, tt := range tests {
        got := Add(tt.a, tt.b)
        if got != tt.want {
            t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.want)
        }
    }
}

可以看到，核心思路就是：

• 定义一个结构体切片，包含输入和期望输出；
• 遍历每一个测试项，调用被测函数并比较结果；
• 如果不一致，用 t.Errorf 报告错误。

测试失败时怎么定位问题？

当某个用例失败时，日志里会显示具体的输入值和期望值，比如：

Add(-1, 1) = 1; want 0

这样你一眼就能看出是哪个组合出了问题，不需要反复调试。这也是表格驱动测试的优势之一：清晰的错误信息 + 明确的测试边界覆盖。

为了增强可读性，也可以给每个测试用例加个名字字段，例如：

tests := []struct {
    name string
    a, b int
    want int
}{
    {"positive numbers", 1, 2, 3},
    {"zero case", 0, 0, 0},
    {"negative and positive", -1, 1, 0},
}

然后在错误信息中打印 tt.name，方便快速定位。

什么时候适合用这种方式？

表格驱动测试适用于以下情况：

• 输入参数和输出结果都是确定的；
• 有很多类似的测试场景；
• 不需要复杂初始化或外部依赖；
• 想要统一处理断言逻辑。

对于一些需要 mock、并发、异步等复杂操作的测试，可能不太适用这种简单结构，但对大多数“纯函数”类测试来说，这是首选方式。

基本上就这些。表格驱动测试虽然看起来简单，但在实际开发中非常实用，尤其在 Go 社区中几乎成为标准做法。只要把测试结构组织好，加上清晰的报错信息，就能大幅提升测试效率和质量。