Go testing.T 怎样让并行子测试隔离数据

表驱动测试加上 t.Parallel() 后，重点不是把循环改快，而是让每个子测试拥有独立的数据边界。最稳妥的写法是：用 t.Run 为每条用例建立子测试，在闭包中固定当前用例，再让子测试调用 Parallel；共享的 map、切片、临时目录和外部资源则必须明确保护或拆开。

Go testing 官方资料：https://pkg.go.dev/testing

并行子测试会在父测试函数返回后参与并发执行，因此循环变量、可变共享对象和清理动作的归属必须在每条用例内部明确。

先把每条用例变成独立数据

并行测试最容易暴露的不是断言错误，而是某个用例改写了另一个用例正在读取的值。表驱动测试中的输入、期望结果和辅助配置，最好都作为当前循环迭代的值传入 t.Run；需要修改时，在子测试内部创建局部副本。

例如下面的测试只让每个子测试读取自己的字符串和期望值。normalize 是被测函数，示例重点在测试数据的归属，而不是函数本身的实现。

package normalize_test

import "testing"

type testCase struct {
	name  string
	input string
	want  string
}

func TestNormalize(t *testing.T) {
	tests := []testCase{
		{name: "trim-space", input: "  go  ", want: "go"},
		{name: "keep-case", input: "Go", want: "Go"},
	}

	for _, tc := range tests {
		tc := tc // 为每个闭包固定一份用例值，兼容旧版本 Go 的循环变量语义。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			got := normalize(tc.input)
			if got != tc.want {
				// 断言只读取当前子测试的数据，不写入共享状态。
				t.Fatalf("normalize(%q) = %q, want %q", tc.input, got, tc.want)
			}
		})
	}
}

这里的 tc := tc 是兼容性写法：闭包捕获的是当前迭代的副本，而不是后来可能被循环覆盖的变量。即使项目已经采用较新的 Go 循环变量语义，保留这行也能把测试意图写得更清楚；新代码则应结合项目的最低 Go 版本统一风格。

用 t.Run 建立子测试生命周期

t.Run 不只是给测试加一个名字。它把每条用例放进单独的测试上下文，失败信息会带上子测试路径，父测试也会等待自己的子测试完成。父函数里适合准备只读配置，子测试里适合创建本条用例专属的可变数据。

func TestParseAmount(t *testing.T) {
	// 只读配置可以由所有子测试共享，避免每条用例重复构造。
	layout := amountLayout()

	for _, tc := range amountCases() {
		tc := tc
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			input := append([]byte(nil), tc.input...)
			got, err := parseAmount(input, layout)
			if err != nil {
				// 错误属于当前用例，直接在子测试上下文中报告。
				t.Fatalf("parse amount: %v", err)
			}
			if got != tc.want {
				t.Fatalf("got %v, want %v", got, tc.want)
			}
		})
	}
}

layout 只有在初始化完成后不再修改，才适合并发读取。input 则明确复制成当前子测试拥有的切片；如果被测函数本身不会修改输入，可以省略复制，但要把这个约定写清楚。对一个会原地改写字节内容的函数，直接把表中的共享切片传进去就会产生数据竞争。

在子测试内部调用 t.Parallel

t.Parallel() 会把当前测试标记为并行测试，并暂停到父测试函数返回后再继续。也就是说，循环很快结束并不代表断言已经完成；父测试仍然负责等待全部子测试收尾。运行时可以用 go test -run TestNormalize -count=1 -v 只观察这一组测试，必要时再用 -parallel 限制同时运行的并行测试数量。

并行的边界应与资源边界一致。下面的示例把共享只读配置留在父测试，把会变化的计数器放进子测试局部变量：

func TestScore(t *testing.T) {
	rules := loadRules() // rules 初始化后只读，子测试可以并发访问。

	for _, tc := range scoreCases() {
		tc := tc
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			attempts := 0 // 每个子测试自己的计数器，不与其他用例共享。
			got := score(rules, tc.input, &attempts)
			if got != tc.want {
				t.Fatalf("score(%q) = %d, want %d", tc.input, got, tc.want)
			}
		})
	}
}

如果某个用例必须修改公共资源，就不要仅靠 t.Parallel 假设它安全。可以给资源加互斥锁、为每个用例分配独立临时目录，或把这类测试留在顺序执行的子测试组中。并行不是测试质量的替代品，隔离不清楚时宁可缩小并发范围。

检查三个容易误判的边界

循环变量会不会串到最后一条？

如果闭包没有固定当前用例，旧版本 Go 的循环变量语义可能让多个子测试观察到同一个值。使用 tc := tc 或把用例作为闭包参数传入，并让 go vet 帮助发现循环闭包问题。

子测试能否修改父测试的切片？

如果切片底层数组仍然相同，子测试的写入会互相影响。对可能被修改的输入使用 append([]T(nil), source...) 做浅复制；元素本身仍是指针或 map 时，还要按元素类型决定是否深复制。

Cleanup 应该放在哪里？

t.Cleanup 注册的函数会在当前测试及其子测试完成后运行。测试专属资源在子测试中创建、在同一个子测试中注册清理；父测试级别的共享资源则等所有子测试结束后再清理。不要让一个并行子测试提前删除另一个测试仍在使用的目录或连接。

最后可以用一张表快速判断：

并行子测试的核心做法可以归纳为：t.Run 负责边界，闭包副本负责数据归属，t.Parallel 负责调度，t.Cleanup 负责资源收尾。只要每条用例的可变状态和清理动作都能独立解释，表驱动测试才适合放心并行。

相关问题

所有 t.Run 都应该调用 t.Parallel 吗？

不应该。只有彼此不共享可变状态、并且外部资源允许并发访问的子测试才适合并行。

t.Parallel 会让单个子测试内部的代码同时执行吗？

不会。它让不同并行子测试之间可以并发；单个子测试函数内部仍按自身代码顺序执行。