测试生命周期

Go 测试里，t.Cleanup 不是注册后马上执行的回调。它会等当前测试，以及当前测试启动的所有子测试都结束后再执行；同一个测试里多次注册时，后注册的清理函数先运行。理解这一点，才能解释“子测试已经结束了，父测试资源为什么还没释放”这类现象。

官方资料：https://pkg.go.dev/testing#T.Cleanup

遇到生命周期混乱时，先问两个问题：这个资源由哪一层测试创建？它的清理回调注册在那一层还是更外层？答案通常比调整 defer 位置更重要。

先看一个父子测试的清理顺序

最容易误判的场景是父测试先注册清理，再调用 t.Run。下面的代码只用日志标记观察顺序，注释中的中文说明了每个回调属于哪一层：

package lifecycle_test

import "testing"

func TestScope(t *testing.T) {
	t.Cleanup(func() {
		// 父测试的资源最后释放，子测试仍可能依赖它。
		t.Log("parent cleanup")
	})

	t.Run("child", func(t *testing.T) {
		t.Cleanup(func() {
			// 子测试结束时执行自己的清理，不会拖到整个测试包结束。
			t.Log("child cleanup")
		})
		t.Log("child body")
	})

	// Run 返回后，子测试及其清理已经结束，父测试才继续。
	t.Log("parent body after child")
}

按生命周期理解，日志关系是：子测试主体、子测试清理、父测试继续执行、父测试清理。关键不是日志文本，而是 t.Run 划出了新的测试节点；子节点结束后，父节点才有机会完成。

为什么父测试的 Cleanup 总是在子测试之后

官方文档对 Cleanup 的定义是：当测试（或子测试）以及它的所有子测试完成时，调用注册的函数。换句话说，父测试的完成条件包含了子测试；父层清理不会抢在仍未完成的子层资源前面执行。

这很适合“父测试创建共享资源、子测试使用共享资源”的场景。例如，父测试可以创建临时目录或测试服务器，子测试只负责使用；父层 Cleanup 负责最后关闭共享资源。子测试自己的临时文件、临时状态，则应该在子测试对象上注册清理。

func TestRepository(t *testing.T) {
	server := newTestServer()
	t.Cleanup(func() {
		// 共享服务器由父测试创建，所有子测试完成后再关闭。
		server.Close()
	})

	for _, name := range []string{"empty", "full"} {
		name := name
		t.Run(name, func(t *testing.T) {
			state := server.NewState()
			t.Cleanup(func() {
				// 每个子测试只清理自己创建的状态。
				state.Reset()
			})
			_ = name
		})
	}
}

资源归属可以用一句话检查：谁创建，谁注册清理；如果资源要跨子测试共享，就把创建和清理都放在共同的父测试层。

同一测试多次注册时，为什么后注册的先执行

t.Cleanup 的顺序是后注册先调用，也就是 LIFO。可以把它理解成一个清理栈：最后压入的资源最先弹出。这样安排能自然匹配“后创建的依赖先释放”的习惯。

func TestCleanupOrder(t *testing.T) {
	t.Cleanup(func() {
		// 先注册的清理最后执行。
		t.Log("close database")
	})
	t.Cleanup(func() {
		// 后注册的清理先执行，先撤销更内层的依赖。
		t.Log("close transaction")
	})
}

所以代码阅读时不要只看清理函数写在文件里的上下位置，还要看实际注册顺序。把“数据库连接”和“事务”都注册在同一测试里时，通常应先清理事务，再关闭连接。

并行子测试和 defer 要怎么区分

并行子测试不会改变清理的归属。父测试仍然要等自己的全部子测试完成；子测试内部注册的清理仍归子测试。区别在于 t.Parallel() 会让子测试的主体延后到调度条件满足后运行，因此不要把父测试在子测试启动后立即执行的代码误认为“所有子测试都结束了”。

func TestParallelGroup(t *testing.T) {
	t.Run("group", func(t *testing.T) {
		t.Cleanup(func() {
			// group 的清理等待 group 下的并行子测试完成。
			t.Log("group cleanup")
		})

		for _, name := range []string{"a", "b"} {
			name := name
			t.Run(name, func(t *testing.T) {
				t.Parallel()
				t.Cleanup(func() {
					// 每个并行子测试只释放自己的资源。
					t.Log("cleanup " + name)
				})
			})
		}
	})
}

defer 也不是 Cleanup 的同义词。defer 绑定当前函数或当前 goroutine 的返回时刻；Cleanup 绑定测试节点的完成时刻，并且会纳入子测试生命周期。测试专属资源优先用 t.Cleanup 表达，普通辅助函数内部的局部资源仍可用 defer。

一张表判断清理代码应该放在哪里

写测试时，先画出测试树，再把资源放到创建它的节点上。这样即使增加子测试、改成并行执行，清理范围也不会因为某个 defer 恰好写在外层而变得模糊。

相关问题

t.Cleanup 会在测试失败时执行吗？

它仍然属于测试完成流程，资源清理不应依赖测试是否成功；但清理函数本身不要掩盖原始失败，必要时只记录信息或谨慎处理错误。

子测试调用 t.Parallel 后父测试会立刻清理吗？

不会。父测试的完成要考虑它启动的子测试，父层 Cleanup 不应提前释放仍被并行子测试使用的共享资源。

同一个测试里的 Cleanup 能不能依赖执行顺序？

可以依赖官方定义的后注册先执行，但更稳妥的做法是让清理顺序与资源创建顺序对应，并在代码旁写清资源归属。