golang如何使用子测试t.Run_golang子测试t.Run使用大全

子测试必须用 t.Run 而非多个 TestXxx 函数，以共享 setup/teardown、避免资源泄漏；循环中需显式拷贝变量（tt := tt）防闭包陷阱；命名禁用斜杠 /；并发子测试须首行调用 t.Parallel()。

子测试必须用 t.Run，不能靠多个 TestXxx 函数模拟

你是不是也写过一堆独立的 TestXxx 函数，以为这样就能把测试场景分得清清楚楚？想法没错，但实践起来就暴露问题了：它们根本共享不了 setup 和 teardown 的逻辑。举个例子，要测试一个数据库操作，每个 TestInsert、TestUpdate 都得自己开连接、建表、最后再清理。这不仅是效率问题，重复劳动还容易埋下隐患——比如一不小心就漏掉了 db.Close()，导致资源泄漏。

而 t.Run 的妙处就在这里。它允许你在顶层的 TestDB 函数里，只做一次统一的初始化。所有子测试都能复用同一套资源（当然，并发安全得自己留心），而且即便某个子测试失败了，也不会影响到其他兄弟测试的执行。

一个典型的反面教材是：当 TestDB_Insert 里触发了 t.Fatal，整个测试进程会直接退出，后面的 TestDB_Update 连跑的机会都没有。这可不是我们想要的测试隔离。

• 每个 t.Run 都拥有自己独立的 *testing.T 实例，状态互不污染。
• 在父测试中注册的 t.Cleanup() 清理函数，会自动继承给所有子测试，省心又安全。
• 子测试失败只会标记自己，其他测试照常进行，测试报告一目了然。

循环中调用 t.Run 必须显式拷贝变量（tt := tt）

这大概是 Go 测试里最经典的“坑”了。写个测试表驱动，在 for 循环里直接调用 t.Run(tt.name, ...)，结果跑完发现，所有子测试用的都是最后一组数据。问题出在哪？Go 的闭包捕获的是变量的地址，而不是变量在那一刻的值。

所以，正确的写法必须在循环体内，第一行就进行显式赋值：

立即学习“go语言免费学习笔记（深入）”；

for _, tt := range tests {
    tt := tt // ? 这一行不能少
    t.Run(tt.name, func(t *testing.T) {
        result := parse(tt.input)
        if result != tt.want {
            t.Errorf("got %v, want %v", result, tt.want)
        }
    })
}

• 少了这一行，所有闭包里的 tt 都指向同一个内存地址，最终值自然是循环结束时的那个。
• 别以为结构体字段是值类型（比如 int、string）就能幸免，同样需要拷贝。如果是指针或者 slice，那问题就更隐蔽了。
• 好消息是，大多数 IDE 或者 linter（比如 staticcheck）都会贴心地给出 SA9003 警告，看到它，千万别手滑忽略。

t.Run 命名不能含斜杠 /，但可用斜杠组织层级语义

给子测试起名叫 "JSON/valid"，看起来层级分明，对吧？但这其实埋了个雷。/ 在 Go 测试框架里，是用来解析嵌套测试层级的分隔符。然而，t.Run 本身并不真正支持物理上的嵌套结构。当你写下 t.Run("a/b", f)，框架只是把它当作一个扁平的名字注册了，只是在输出日志和用 -run 匹配时，会按 / 来切分路径。

问题随之而来：如果你执行 go test -run=TestFoo/a，它不仅会匹配名为 a 的子测试，连 a/b 也会被一并触发，这很容易导致误跑测试。

更稳妥的做法是：保持子测试名称本身是扁平的，不含斜杠，通过父子调用关系自然形成逻辑层级。比如：

func TestParse(t *testing.T) {
    t.Run("JSON_valid", func(t *testing.T) { /* ... */ })
    t.Run("JSON_invalid_empty", func(t *testing.T) { /* ... */ })
    t.Run("XML_malformed", func(t *testing.T) { /* ... */ })
}

• 运行时，输出会自动呈现为 TestParse/JSON_valid 这样的格式，调试定位足够清晰。
• 你依然可以用 go test -run=TestParse/JSON 进行模糊匹配，但不会因为名字中间有个 / 而产生歧义。
• 务必避免使用像 "../x"、"a//b" 这类看起来像非法路径的命名，某些 CI 工具或 IDE 在解析时可能会出错。

并发子测试要小心：必须在子测试函数首行调用 t.Parallel()

t.Parallel() 的作用需要明确：它并非一个“开启并发”的魔法开关，而是向测试调度器声明：“我这个子测试可以和其他也声明了并发的测试一起并行运行”。关键在于，这个声明只在当前子测试函数的作用域内生效，而且，它必须是函数体里的第一行代码——如果放在后面，调用会被静默忽略，测试将退化为串行执行。

来看一个典型的错误写法：

t.Run("hea vy_test", func(t *testing.T) {
    setup() // ❌ setup 放在 t.Parallel() 前，会导致并发失效
    t.Parallel()
    doWork()
})

正确的顺序应该是这样：

t.Run("hea vy_test", func(t *testing.T) {
    t.Parallel() // ✅ 必须放在第一行
    setup()
    doWork()
})

• 在父测试函数里调用 t.Parallel() 是没意义的，它只作用于子测试。
• 一旦开启并发，就必须警惕共享非线程安全的资源，比如全局的 map 或者未加锁的结构体字段。
• 如果 setup 阶段成本很高（例如需要启动一个 HTTP 服务器），最好在父测试中完成，并确保它能被所有子测试安全地复用。

说到底，子测试真正的复杂度，往往不在于语法本身，而在于对资源生命周期边界的精细控制——数据库连接到底该在哪儿关闭？Mock 对象是否需要为每个子测试单独重置？t.Cleanup() 注册的时机是否覆盖了所有可能的分支？这些细节，光靠漂亮的命名和清晰的结构是掩盖不住的，必须实实在在地体现在代码逻辑里。