1、Go测试基础：Go语言测试框架介绍、testing包核心概念、Test函数签名与命名规范、表格驱动测试入门

大家好，我是你们的老朋友。今天咱们正式开始《Go单元测试与集成测试实战》的第一章。

说实话，我见过太多Go开发者，写业务代码溜得飞起，一提到写测试就皱眉头。嗯，这其实挺可惜的。因为Go语言在设计之初，就把测试放到了一个很高的位置。你想想看，go test这个命令是内置的，不需要装任何第三方工具。这在编程语言里其实不多见。

Go语言测试框架：为什么它这么香？

Go的测试框架，说白了就是一套轻量级的工具链。它不像Java的JUnit那样需要一堆注解，也不像Python的pytest那样需要各种插件。Go的做法很简单——约定大于配置。

我个人习惯把Go的测试框架总结为三个核心特点：

• 零依赖：标准库的testing包就是全部家当
• 约定驱动：文件名、函数名、参数名都有固定规则
• 速度优先：编译快、执行快，反馈周期短

我在项目中遇到过很多次，团队从其他语言转Go，最不适应的就是测试。但一旦习惯了这种「写测试就像写代码一样自然」的节奏，就再也回不去了。

testing包核心概念：你需要记住的几样东西

testing包是Go测试的基石。它提供了几个核心类型，我挑最重要的说：

类型	用途	常用方法
*testing.T	单元测试的控制句柄	Error(), Fatal(), Log()
*testing.B	基准测试的控制句柄	N, ReportAllocs()
*testing.M	测试主函数，控制全局行为	Run()

这里有个小细节，很多人容易搞混Error和Fatal的区别。我简单解释一下：

• t.Error()：报告测试失败，但继续执行当前测试函数
• t.Fatal()：报告测试失败，并立即停止当前测试函数

Test函数签名与命名规范：规矩就是规矩

Go的测试函数必须遵守一套严格的签名规则。不遵守？编译器直接不认。这其实是个好事，省得大家争论「到底该叫testUserLogin还是TestUserLogin」这种问题。

规则很简单，就三条：

1. 函数名必须以Test开头，后面跟大写字母开头的单词
2. 参数必须是*testing.T，且没有返回值
3. 函数必须放在_test.go结尾的文件里

举个例子：

// 正确的写法
func TestAdd(t *testing.T) {
    // 测试逻辑
}

// 错误的写法（编译器不会识别为测试函数）
func testAdd(t *testing.T) {  // 小写t开头
}

func TestAdd() {  // 缺少*testing.T参数
}

我个人习惯给测试函数起名时，遵循「被测函数名_场景_预期结果」的模式。比如：

func TestAdd_PositiveNumbers_ReturnsSum(t *testing.T) {
    // ...
}

func TestAdd_NegativeNumbers_ReturnsCorrectResult(t *testing.T) {
    // ...
}

这样命名的好处是，测试失败时，你一眼就能看出是哪个场景出了问题。

表格驱动测试入门：优雅地处理多场景

好，终于到了我最喜欢的部分——表格驱动测试。这可以说是Go测试中最优雅的模式之一。

你想想看，如果我们要测试一个加法函数，有10组不同的输入输出。最笨的办法是写10个测试函数，或者在一个函数里写10遍if ... else ...。但表格驱动测试的做法是：

func TestAdd(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        expected int
    }{
        {"两个正数", 1, 2, 3},
        {"正数和零", 5, 0, 5},
        {"两个负数", -1, -2, -3},
        {"正数和负数", 10, -5, 5},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            result := Add(tt.a, tt.b)
            if result != tt.expected {
                t.Errorf("Add(%d, %d) = %d, 期望 %d", tt.a, tt.b, result, tt.expected)
            }
        })
    }
}

看到没？核心思路就是把测试数据放在一个结构体切片里，然后用t.Run()创建子测试。这样做的好处太多了：

• 可读性强：测试数据和测试逻辑分离，一目了然
• 易于扩展：加一个新用例，只需要在切片里加一行
• 独立执行：每个子测试可以单独运行，互不干扰

我在项目中遇到过最典型的场景是测试HTTP处理函数。不同的请求参数、不同的Header、不同的Body，用表格驱动测试简直不要太爽。你只需要定义好输入和期望输出，剩下的交给循环就好。

嗯，这里要提醒一下：表格驱动测试虽然好，但也不是万能的。如果你的测试逻辑本身就很复杂（比如涉及多个步骤的状态机），那还是老老实实写独立的测试函数吧。别为了用表格而用表格。

总结一下今天的内容

今天我们聊了Go测试的四个基础点：

1. Go的测试框架轻量、零依赖，靠约定驱动
2. testing包的核心类型*testing.T，以及Error和Fatal的区别
3. Test函数的命名规范和签名要求，以及我推荐的命名模式
4. 表格驱动测试的基本写法，以及它为什么是Go测试的「标配」

说实话，这些内容看起来简单，但都是基本功。我见过太多人跳过基础直接上mock框架，结果遇到问题一脸懵。所以，我建议你把今天的内容亲手敲一遍，感受一下go test的反馈速度。

下一章，我们会深入testing包的高级用法，包括如何组织测试套件、如何做测试覆盖率分析。到时候见！