Go TestMain 怎么统一创建测试依赖并保证退出码

当一组 Go 测试都依赖同一个临时目录、测试服务或客户端时，可以把创建和清理集中到 TestMain。关键写法不是“把所有初始化都塞进去”，而是明确三件事：依赖在 m.Run() 之前可用，清理发生在测试完成之后，最终退出码仍然来自测试结果。初始化本身失败时，再单独返回非零码并把原因写到标准错误。

最稳的结构是：创建依赖并检查错误，执行 m.Run() 保存返回值，显式清理，最后调用 os.Exit(code)。这样测试失败不会被清理逻辑覆盖，夹具失败也不会被误报成通过。

TestMain 的职责边界要先划清

Go 官方 testing 文档把 TestMain(m *testing.M) 定义为测试或基准程序的额外 setup、teardown 入口。测试包装器会调用它，而 m.Run() 负责真正执行测试并返回退出码。适合放进 TestMain 的通常是包内共享且创建成本较高的资源，例如一次性的 httptest.Server、只读配置、临时工作区或测试客户端。

单个测试用例会修改的对象不要直接做成全局共享变量；否则并行测试之间会互相污染。更好的做法是让全局依赖保持只读，或者在每个 TestXxx 内再复制一份可变状态。把“共享连接”误当成“共享数据”是 TestMain 最常见的边界错误。

统一创建依赖，最后保留 m.Run 的结果

下面的示例用临时目录和测试服务模拟包级依赖。示例没有把真实业务连接写死在文章中，重点是资源对象、清理函数和退出码之间的关系。

package example_test

import (
	"flag"
	"fmt"
	"net/http/httptest"
	"os"
	"testing"
)

type testDeps struct {
	workDir string
	server  *httptest.Server
}

var deps testDeps

func newTestDeps() (testDeps, error) {
	// 共享依赖只创建一次，返回的 cleanup 由 TestMain 统一负责
	workDir, err := os.MkdirTemp("", "example-test-")
	if err != nil {
		return testDeps{}, err
	}
	server := httptest.NewServer(okHandler())
	return testDeps{workDir: workDir, server: server}, nil
}

func TestMain(m *testing.M) {
	// TestMain 中若依赖自定义 flag，要先显式解析
	flag.Parse()

	created, err := newTestDeps()
	if err != nil {
		// 初始化失败不是某个 TestXxx 的失败，直接报告并返回非零码
		fmt.Fprintln(os.Stderr, "create test dependencies:", err)
		os.Exit(1)
	}
	deps = created

	// m.Run 的返回值代表测试整体结果，先保存再执行清理
	code := m.Run()
	created.server.Close()
	_ = os.RemoveAll(created.workDir)
	os.Exit(code)
}

这个版本故意把清理写在 os.Exit(code) 之前。因为显式 os.Exit 不会执行当前 goroutine 中尚未运行的 defer；如果写成 defer created.server.Close() 再调用 os.Exit，服务就可能没有关闭。若不需要显式处理退出码，也可以在清理使用 defer 后直接调用 m.Run() 并返回，让测试包装器接管它的结果，但团队应统一一种约定。

初始化失败和测试失败要分开处理

测试依赖创建失败时，继续调用 m.Run() 往往只会制造一串次生错误：每个测试都因为同一个空客户端失败，日志却看不出根因。因此初始化函数应返回 error，先写到 os.Stderr，再用非零退出码结束。已经创建了一部分资源时，要在退出前清理这部分资源，不能只清理“全部创建成功”的路径。

测试正常启动后，m.Run() 的返回值必须原样保留。不要在清理函数里把它重置为 0，也不要用固定的 os.Exit(1) 替代它。这样 CI 才能区分测试失败、测试进程异常和夹具初始化失败。

上线 CI 前检查这几个 TestMain 坑

第一，只有当 TestMain 依赖命令行参数时才需要在其中调用 flag.Parse；测试函数运行时标志已经会被解析。第二，包级共享依赖必须能被并行测试安全地读取，写操作应改为每用例隔离。第三，清理要覆盖服务、临时目录和连接等外部资源，不能只释放最显眼的一个对象。第四，日志里同时保留“夹具初始化失败”和“测试返回码”，否则 CI 上很难判断是哪一层出问题。

常见问题

TestMain 里一定要调用 os.Exit 吗？

不一定。直接调用 m.Run() 时，测试包装器会接管它的结果；需要明确控制清理顺序或区分初始化失败时，可以保存返回值后显式退出。

为什么 TestMain 里的 defer 没有执行？

通常是因为代码先调用了 os.Exit。它会立即结束进程，不执行 defer；要么改为返回，让包装器退出，要么把必要清理显式写在 os.Exit 之前。

共享依赖应该放在 TestMain 还是每个测试里？

创建昂贵且只读的包级资源适合放在 TestMain；会被测试修改、需要隔离或必须按用例重置的状态，应留在单个测试或子测试中。

参考：Go testing 包的 TestMain 说明、Go 官方文档。