Go 表驱动测试怎么清理临时文件和测试资源

Go 表驱动测试里，最稳妥的清理方式是：把资源创建放进对应的 t.Run，临时目录优先交给 t.TempDir()，其他文件、连接或模拟资源用 t.Cleanup 注册回收函数。这样每个子测试都有自己的生命周期，即使断言失败、调用 t.Skip，清理也不会依赖测试代码走到最后一行。

记住一个边界：谁创建资源，谁就应该在同一个测试作用域注册清理；父测试创建的共享资源才放在父级清理。

问题现场：为什么表驱动测试越跑越脏

常见写法是在循环外创建一个目录或文件，然后让多个用例复用。第一次运行可能没有问题，但某个用例失败后，后续用例仍能看到旧文件；如果测试改成并行执行，删除动作还可能和另一个用例的读写同时发生。另一种写法是手动 defer os.RemoveAll(dir)，它只适合当前函数中已经明确的资源范围，遇到嵌套子测试时很容易把父子资源混在一起。

排查时先问两个问题：这个资源属于整组测试，还是只属于某一行表数据？它是否会被并行子测试同时使用？只要答案是“只属于某一行”，就不要在外层循环创建。

先收紧作用域：每个子测试拥有自己的临时目录

testing.T.TempDir 会返回给当前测试使用的临时目录，并在当前测试及其子测试结束后自动删除。它适合放测试输入、生成文件和中间产物，不需要再手写删除逻辑。关键是调用位置：必须在 t.Run 的回调内部，这样每个用例得到的路径天然不同。

func TestRenderTable(t *testing.T) {
	tests := []struct {
		name  string
		input string
	}{
		{name: "empty", input: ""},
		{name: "markdown", input: "# title"},
	}

	for _, tc := range tests {
		t.Run(tc.name, func(t *testing.T) {
			dir := t.TempDir()
			input := filepath.Join(dir, "input.txt")
			if err := os.WriteFile(input, []byte(tc.input), 0o600); err != nil {
				t.Fatalf("write input: %v", err)
			}
			// 被测函数只接收本用例的 input，不会读到其他行的数据。
			_ = input
		})
	}
}

这里不需要为了删除文件再注册一个 Cleanup。如果要保留失败现场，应改变测试运行方式或复制需要的诊断文件，而不是让所有用例共享一个可变目录。

需要显式释放时，用 T.Cleanup 记录资源责任

连接、监听器、环境变量或自定义 fake 通常不能由 TempDir 代劳。创建成功后立即注册清理函数，能避免中途 Fatal 时遗漏释放。T.Cleanup 在当前测试及其子测试结束后执行，而且多个清理函数按后进先出调用，所以应先注册外层资源，再注册依赖它的内层资源。

func openFixture(t *testing.T, dir string) *os.File {
	t.Helper()
	file, err := os.Create(filepath.Join(dir, "fixture.txt"))
	if err != nil {
		t.Fatalf("create fixture: %v", err)
	}
	t.Cleanup(func() {
		if err := file.Close(); err != nil {
			t.Errorf("close fixture: %v", err)
		}
	})
	return file
}

func TestLoadTable(t *testing.T) {
	for _, name := range []string{"cached", "fresh"} {
		t.Run(name, func(t *testing.T) {
			dir := t.TempDir()
			fixture := openFixture(t, dir)
			_, _ = fixture.WriteString(name)
		})
	}
}

清理函数要尽量短，并把释放错误报告给测试；不要在里面继续创建需要另一个 cleanup 的复杂资源。资源创建失败时没有成功资源，就不应该注册一个假清理函数。

并行子测试：共享资源必须上移，独占资源必须下沉

调用 t.Parallel() 后，多个子测试可能同时运行。文件路径、缓冲区和可变 fake 应下沉到各自的回调中；只读配置或真正线程安全的客户端才适合由父测试创建并共享。父级的 t.Run 会等待并行子测试完成，因此可以把共享资源的关闭注册在父级。

func TestQueryTable(t *testing.T) {
	client := newReadOnlyClient()
	t.Cleanup(func() { client.Close() })

	for _, tc := range []struct {
		name string
		want int
	}{
		{name: "one", want: 1},
		{name: "two", want: 2},
	} {
		tc := tc
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			dir := t.TempDir()
			got := queryAndWrite(client, dir, tc.name)
			if got != tc.want {
				t.Fatalf("got %d, want %d", got, tc.want)
			}
		})
	}
}

如果共享客户端内部有可变状态，不能因为它的 Close 写在父级就认为它适合并行访问。先确认线程安全，再决定共享；否则把客户端也放入每个子测试并单独 cleanup。

复查清理是否可靠：失败、跳过和重复运行

用一个会失败的表项验证：清理函数仍执行；用 t.Skip 验证跳过不会留下目录；用 go test -run TestRenderTable/markdown -count=5 重复运行，确认用例之间没有依赖上一次的文件。若测试需要保留诊断信息，建议在 cleanup 前把必要内容写到日志或指定产物目录，不要通过禁用清理来“方便调试”。

最后可以按这张表做选择：

相关问答

t.Cleanup 和 defer 应该怎么选？

只覆盖当前函数、且不涉及子测试的简单局部资源可以用 defer；需要绑定 testing 生命周期，尤其是子测试、失败和并行场景时，用 t.Cleanup 更清楚。

每个表项都必须手动删除临时文件吗？

不必。把文件放在该表项的 t.TempDir 中，测试和它的子测试结束后目录会自动删除；只有目录外的资源或需要显式关闭的对象才需要额外注册 cleanup。

参考：Go testing 包官方文档。