Go testing.T.Failed 怎样在清理逻辑中判断测试结果

我在给 Go 测试补“失败时保留现场”时，最开始把状态判断写在断言之后。这个写法看似直接，却很快遇到两个问题：后面的子测试还没有结束，判断结果可能过早；资源清理回调里又需要知道整个测试最终是否失败。更稳妥的入口是 testing.T.Failed()：它读取当前测试对象已经记录的失败状态，适合放在 t.Cleanup 中做最终诊断。

官方文档：https://pkg.go.dev/testing#T.Failed

t.Failed() 不是重新执行断言，也不是“是否跳过”的判断。它回答的是：这个 *testing.T 对应的测试函数到当前时刻是否已经失败。

接口目标：读取失败状态，不改变测试状态

t.Failed() 返回一个布尔值。t.Error、t.Errorf、t.Fail 或 t.Fatal 等路径会把当前测试标记为失败；Failed 只负责读取这个标记。它不会清除失败，也不会把通过测试改成失败。

这点很适合做“条件性收尾”：失败时打印诊断目录、保留中间文件，成功时执行普通清理。判断要放在真正的收尾位置，而不是在某个断言之后立即下结论。

把判断放进 t.Cleanup：看当前测试的最终状态

官方文档规定，t.Cleanup 注册的函数会在当前测试及其子测试完成后调用，并且按后注册先调用。也就是说，父测试的 Cleanup 能等子测试结束；在这个回调里读取 t.Failed()，比在父测试函数中间读取更接近最终状态。

func TestImport(t *testing.T) {
    workDir := t.TempDir() // 让测试框架创建临时目录

    t.Cleanup(func() {
        if t.Failed() { // 失败时保留路径，便于 CI 收集诊断文件
            t.Logf("测试失败，诊断目录：%s", workDir)
            return
        }
        // 这里放成功路径的额外清理；TempDir 自己也会注册清理函数
        t.Log("测试通过，按正常策略收尾")
    })

    if err := importData(workDir); err != nil {
        t.Fatalf("导入失败：%v", err) // 标记失败并结束当前测试函数
    }
}

这里的关键不是把 t.Failed() 当成删除开关，而是明确“谁拥有收尾责任”。如果失败现场需要上传，应在回调中把目录交给 CI 的工件收集逻辑；如果只是普通临时目录，仍然可以让 TempDir 的内置 Cleanup 负责删除。多个 Cleanup 的注册顺序也要一起考虑，避免自定义回调先删掉另一个回调还要读取的文件。

父测试与子测试：Failed 的归属边界

每个 *testing.T 都有自己的状态。子测试调用失败方法时，失败会沿父子关系影响父测试；因此父测试的 Cleanup 可以观察到子测试失败。但“子测试本身的 Cleanup”和“父测试的 Cleanup”不是同一个回调位置，应该把资源放在拥有它的测试对象上。

func TestImport(t *testing.T) {
    t.Cleanup(func() {
        if t.Failed() { // 父测试收尾时可看到子测试带来的失败状态
            t.Log("父测试需要保留诊断信息")
        }
    })

    ok := t.Run("invalid-input", func(t *testing.T) {
        t.Cleanup(func() {
            if t.Failed() { // 这里只判断 invalid-input 这个子测试
                t.Log("子测试保留自己的局部诊断")
            }
        })
        t.Error("输入不符合约定") // 子测试失败也会影响父测试结果
    })

    if !ok {
        t.Log("t.Run 已报告该子测试没有成功")
    }
}

t.Run 的返回值适合做“这个子测试是否成功”的即时分支，但并行子测试在调用 t.Parallel() 后可能尚未完成，不能把返回值当成所有并行工作都已结束后的总状态。需要在父测试最终收尾时判断，就把逻辑放进父级 t.Cleanup。

错误模型：Failed、Run 返回值和 Skipped 不要混用

跳过不是失败：一个测试直接调用 t.Skip，通常不会因为跳过而让 Failed() 变成 true；但如果它先调用了 t.Error，再调用 t.Skip，源码明确保留原有失败状态。需要区分这两类结果时，同时读取 Failed 和 Skipped，不要只看日志文本。

我的使用结论

• 想在测试收尾时判断最终失败：把 t.Failed() 放进对应的 t.Cleanup。
• 想在父函数里马上分支：使用 t.Run 的返回值，但注意并行子测试的边界。
• 想判断跳过：使用 t.Skipped()；失败和跳过可能同时出现，取决于先前是否已经记录失败。

对我来说，Failed 最有价值的地方不是少写一个布尔变量，而是把“测试状态读取”和“资源清理责任”分开：断言负责报告问题，Cleanup 负责决定怎样收尾，父子测试各自管理自己的现场。

常见问题

t.Failed() 会主动让测试失败吗？

不会。它只读取已经存在的失败标记，不能替代 t.Fail、t.Error 或 t.Fatal。

父测试的 Cleanup 能看到子测试失败吗？

可以。父级 Cleanup 在子测试完成后运行，父测试状态也会体现子测试失败；但子测试自己的 Cleanup 仍只负责它自己的资源。