Go testing.T Cleanup协调 Parallel 测试与清理动作的边界

我在把表格驱动测试改成并行后，最容易误判的是“测试函数返回了，资源就可以清了”。实际上，t.Parallel() 只是把当前子测试交给并行调度；真正的组级边界由外层 t.Run 决定。实用的分层方式是：共享 fixture 由父级注册清理，每个子测试用自己的 t.Cleanup 释放局部资源，外层 Run 返回后再清理整组资源。

先把共享 fixture 与子测试资源分成两层

假设一组测试共享一个内存仓库，但每个用例还需要独立的临时目录。共享仓库的生命周期属于外层分组；临时目录、临时文件和用例级 mock 则属于子测试。不要让每个并行子测试都去关闭共享仓库，也不要把局部资源的清理推迟到整个顶层测试结束。

func TestUsers(t *testing.T) {
	// 共享 fixture 只由外层测试创建和释放。
	store := newMemoryStore()
	t.Run("parallel-cases", func(t *testing.T) {
		t.Cleanup(func() {
			// 组级清理发生在这一组子测试全部结束之后。
			store.Close()
		})

		for _, tc := range []struct {
			name string
			want int
		}{
			{name: "admin", want: 1},
			{name: "guest", want: 0},
		} {
			tc := tc // 复制当前用例，避免并行闭包读到下一轮数据。
			t.Run(tc.name, func(t *testing.T) {
				t.Parallel()
				dir := t.TempDir() // 子测试独享临时目录，由 testing 自动清理。
				_ = dir
				if got := store.Count(tc.name); got != tc.want {
					t.Fatalf("count = %d, want %d", got, tc.want)
				}
			})
		}
	})
}

这里的关键不是“把所有清理都写成 Cleanup”，而是先确定所有权。父级拥有 store，子级拥有临时目录；所有权清楚，清理回调才不会互相踩踏。

调用 Parallel 前先固定循环变量和输入状态

并行测试中，闭包捕获的是变量而不是某一轮循环的快照。即使测试代码看起来很短，也应该在 t.Run 前复制当前用例；如果还要写入共享 fixture，则应使用线程安全接口或把写入对象改成每个子测试独享。

可以把边界记成下面这张表：

如果共享对象确实需要并行写入，就把锁或并发安全容器作为 fixture 的一部分；不要寄希望于 Cleanup 帮你解决数据竞争。清理只定义生命周期，不会自动提供同步。

用外层 T.Run 把并行组的等待点说清楚

官方 testing 文档明确说明，Run 不会在并行子测试完成前返回。因此，组级清理应放在承载这组并行用例的 Run 之后，或者注册在这个分组的 Cleanup 中。这样既能保证资源还在，也能让测试结构直接表达“先跑完一组，再释放一次”。

常见的反例是：在循环体里关闭共享客户端，或者在顶层测试函数刚调用完几个 t.Run 就把 fixture 清空。前者会让其他并行用例读到已关闭对象，后者则把组边界和资源边界混在一起。遇到偶发失败时，先打印 t.Name() 标记所有权，再检查清理回调是否注册在正确层级。

func TestParallelGroup(t *testing.T) {
	fixture := newFixture()
	t.Run("group", func(t *testing.T) {
		// 组级回调只负责这组测试拥有的共享对象。
		t.Cleanup(func() { fixture.Reset() })
		for _, name := range []string{"cold", "warm"} {
			name := name // 固定本轮名称，避免闭包捕获后续值。
			t.Run(name, func(t *testing.T) {
				t.Parallel()
				if err := fixture.Check(name); err != nil {
					// 失败只结束当前子测试，不提前关闭共享 fixture。
					t.Fatalf("check %s: %v", name, err)
				}
			})
		}
	})
	// 外层 Run 返回后，group 内的并行子测试已经完成。
}

常见问题

Cleanup 会不会在 Parallel 子测试开始前就执行？

不会。它绑定的是当前测试上下文；当前测试及其子测试完成后才会执行。真正要注意的是注册层级：注册在子测试上的回调不会替代父级共享资源的清理。

并行测试能不能直接修改同一个 map？

不能把生命周期管理当成并发保护。需要写入时使用互斥锁、线程安全容器，或让每个子测试拿到独立副本，并在测试结束后再合并结果。

为什么还要包一层 T.Run？

它把一组并行用例变成清晰的等待边界：外层 Run 返回后，父级才进入组级清理或下一阶段断言，结构比散落的顶层调用更容易维护。

把 Cleanup 当作“当前测试所有权的释放协议”，把 Parallel 当作“调度声明”，再用外层 Run 明确等待点，通常就能稳定处理并行测试的清理动作。剩下的并发安全问题，仍需要锁、隔离数据或独立 fixture 来解决。