Go testing.T.Errorf 怎样保留失败上下文并继续执行测试

在 Go 的表格测试里，如果一个样例失败后还希望继续检查同一用例的其他字段，使用 t.Errorf。它会把格式化后的信息写入测试日志，再把当前测试标记为失败，但不会像 t.Fatalf 一样立刻结束测试函数。

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

简单记忆：还能继续执行，就用 Errorf；后续代码依赖前置结果、继续执行会产生误导或风险，就用 Fatalf。两者都会让测试失败，差别在控制流。

先看清 Errorf 到底改变了什么

testing.T.Errorf 可以理解为“格式化记录一条错误，再执行 Fail”。因此它同时完成两件事：把实际值、期望值和输入样例写入测试输出；把当前测试状态置为失败。它不会回滚已经执行的代码，也不会跳过后面的语句。

package demo

import "testing"

func TestAdd(t *testing.T) {
	got := 2 + 2
	want := 5
	if got != want {
		// Errorf 保留格式化上下文，并让当前测试继续向下执行。
		t.Errorf("Add() = %d, want %d", got, want)
	}

	// 这里仍然会执行，但最终结果仍是失败。
	t.Log("后续检查仍可运行")
}

这段代码的输出重点不是“程序被中断”，而是测试记录中会出现一条带调用位置的错误信息。即使后面的日志出现了，测试进程也不会把这个失败变成成功。

表格测试中怎样保留多个失败项

对一组输入做多个独立断言时，Errorf 的价值最明显。每个检查都使用清晰的字段名和输入值，失败后继续检查下一个字段，修复时不必反复运行才能看到第二个问题。

func TestNormalizeUser(t *testing.T) {
	cases := []struct {
		name  string
		input string
		want  string
	}{
		{name: "trim", input: "  Ada ", want: "Ada"},
		{name: "empty", input: "", want: "unknown"},
	}

	for _, tc := range cases {
		t.Run(tc.name, func(t *testing.T) {
			got := normalize(tc.input)
			if got != tc.want {
				// 把样例名、输入、实际值和期望值一次写全，便于定位。
				t.Errorf("normalize(%q) = %q, want %q", tc.input, got, tc.want)
			}
			// 独立断言仍可继续执行，适合收集同一用例的多个差异。
			if len(got) == 0 {
				t.Errorf("normalize(%q) returned an empty result", tc.input)
			}
		})
	}
}

这里每个 t.Run 都有自己的失败状态。若一个子测试中有两个 Errorf，它们会共同把这个子测试判为失败；其他子测试仍按测试框架的规则执行。

什么时候必须换成 Fatalf

如果后续代码无法在前置条件失败后正确运行，就不要为了“多打印一条日志”继续执行。例如打开测试夹具失败时，后面的读取会使用无效对象，得到的错误只会掩盖真正原因：

func TestFixture(t *testing.T) {
	data, err := loadFixture()
	if err != nil {
		// 前置数据不存在时，继续使用 data 会让后续错误失去意义。
		t.Fatalf("loadFixture() failed: %v", err)
	}

	if got := parse(data); got == "" {
		// 解析结果仍然可比较，所以这里可以继续用 Errorf。
		t.Errorf("parse(fixture) returned an empty result")
	}
}

Fatalf 会记录格式化信息，然后调用 FailNow。官方实现还明确要求 FailNow 只能从运行测试的 goroutine 调用；后台 goroutine 应通过 channel、错误收集器或同步点把结果交回测试函数，再由测试 goroutine 报告。

几个容易混淆的边界

• Errorf 不等于警告：它会让当前测试失败，不能用来记录“可忽略但仍成功”的提示；这种信息用 Logf 更合适。
• 不要把 Fatalf 放进后台 goroutine：终止式方法依赖测试 goroutine 的生命周期，后台任务应先完成同步，再集中报告。
• 辅助函数要保留调用位置：封装断言时在辅助函数里调用 t.Helper()，错误日志会更接近真正的测试调用点。

最终可以按一条规则选择：失败后仍有独立检查，使用 Errorf 收集上下文；失败后状态已经不可信，使用 Fatalf 尽早停止当前测试。无论选择哪一个，错误消息都应包含输入、实际值和期望值。

常见问题

Q：调用 Errorf 后测试函数还会继续吗？
会。它标记失败并继续当前函数，除非后续代码主动返回或发生其他控制流变化。

Q：Errorf 失败后能不能把测试重新标记为成功？
不能。失败状态已经记录，后续通过的断言不会清除它。

Q：只想输出信息但不让测试失败怎么办？
使用 t.Logf；它只写测试日志，不调用 Fail。