Go testing.T.Run 返回 false 时怎样让父测试保留失败上下文

在表格驱动测试里，t.Run 的返回值很适合帮助父测试做一次摘要判断，但它不能替代子测试本身的错误日志。更稳妥的做法是：给每个子测试使用能表达输入的名称，在子测试内部记录关键上下文；父测试只在拿到 false 时补充一条汇总信息。

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

下面按“返回值是什么—怎样记录上下文—并行时哪里不同”的顺序展开。

T.Run 的 bool 返回值说明了什么

t.Run(name, f) 会启动一个名为 name 的子测试，并返回一个布尔值。通常可以这样理解：

• 返回 true：子测试完成时没有被标记为失败。
• 返回 false：子测试已经失败，常见原因是调用了 Errorf、Fail 或 Fatalf。
• 如果子测试调用了 t.Parallel()，Run 可能在子测试真正完成前返回；此时不能把返回值当成最终结果。

需要注意，子测试失败本身就会让父测试失败。父层再次调用 t.Errorf 不是“把失败传递下去”的必需动作，它更多用于补一条汇总上下文。

先让子测试名称和日志承担定位工作

如果所有案例都叫 case，失败输出只能告诉你某个位置出错。把输入边界放进名称，再在断言前记录关键值，排错会直接很多。

package example

import "testing"

func TestPrices(t *testing.T) {
	cases := []struct {
		name string
		got  int
		want int
	}{
		{name: "empty-cart", got: 0, want: 0},
		{name: "coupon-10", got: 90, want: 90},
	}

	for _, tc := range cases {
		tc := tc // 为每个子测试固定当前案例，避免闭包读取后续迭代值。
		t.Run(tc.name, func(t *testing.T) {
			t.Logf("输入案例=%s，实际=%d，期望=%d", tc.name, tc.got, tc.want) // 失败或 -v 时保留关键上下文。
			if tc.got != tc.want {
				t.Errorf("结果不匹配：got=%d want=%d", tc.got, tc.want) // 标记子测试失败，但让测试框架继续收集信息。
			}
		})
	}
}

这里的重点不是把日志写得越多越好，而是让一条失败记录同时包含案例名、实际值和期望值。T.Logf 的内容会在失败时保留；需要观察通过案例的日志时，再使用 -v。

收到 false 时，父测试怎样补一条摘要

对不使用 t.Parallel() 的子测试，可以检查 Run 的返回值，并在父层补充一条不重复断言的摘要。不要再次调用 t.Errorf，否则同一个失败可能出现两份错误。

func TestPricesWithSummary(t *testing.T) {
	cases := []struct {
		name string
		got  int
		want int
	}{
		{name: "empty-cart", got: 0, want: 0},
		{name: "coupon-10", got: 88, want: 90},
	}

	for _, tc := range cases {
		tc := tc // 固定当前案例，父层日志要和对应子测试保持一致。
		if ok := t.Run(tc.name, func(t *testing.T) {
			if tc.got != tc.want {
				t.Errorf("结果不匹配：got=%d want=%d", tc.got, tc.want) // 真正的失败在子测试中产生。
			}
		}); !ok {
			t.Logf("父测试收到失败摘要：子测试=%q", tc.name) // 只补定位信息，不重复标记失败。
		}
	}
}

这段代码的效果是：子测试输出具体断言，父测试输出失败案例名称。父测试仍然会因为子测试失败而失败，因此不要把 Run 的返回值误解为“需要手动向上抛错”。

并行子测试为什么不能简单依赖返回值

并行子测试调用 t.Parallel() 后会暂停当前子测试，父测试可以继续创建其他子测试。此时 Run 返回的是“进入并行等待点前”的状态，不适合用来判断子测试最终是否通过。

func TestParallelPrices(t *testing.T) {
	cases := []struct {
		name string
		got  int
		want int
	}{
		{name: "coupon-10", got: 88, want: 90},
		{name: "coupon-20", got: 80, want: 80},
	}

	for _, tc := range cases {
		tc := tc // 并行闭包必须保存当前案例，不能直接引用循环变量。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel() // 调用后由测试框架在父测试返回后安排执行。
			t.Logf("并行案例=%s，实际=%d，期望=%d", tc.name, tc.got, tc.want) // 让 -v 输出带上案例上下文。
			if tc.got != tc.want {
				t.Errorf("结果不匹配：got=%d want=%d", tc.got, tc.want) // 最终失败由子测试和父测试共同呈现。
			}
		})
	}
}

并行场景应把关键日志和断言放在子测试内部，并依赖测试名称定位。查看完整上下文时运行：

# 使用 -v 展开每个子测试的名称和日志，便于定位最终失败案例。
go test -run '^TestParallelPrices$' -v ./...

一张表记住选择方式

相关问题

父测试会自动因为子测试失败而失败吗？

会。子测试的失败状态会纳入父测试结果，父层通常只需要补充上下文，不需要手动再次失败。

为什么通过测试的 Logf 看不到？

测试日志默认主要在失败时显示；需要看通过案例的日志时使用 go test -v。

Fatalf 能从 goroutine 中调用吗？

不要在测试创建的其他 goroutine 中调用依赖当前测试 goroutine 的终止方法；把错误通过通道或结果值交回测试 goroutine，再由子测试调用断言方法。

总结：顺序子测试可以用 Run 的 false 补充父层摘要，但真正的失败原因应留在子测试名称、日志和断言中；并行子测试则应把定位信息放在子测试内部，不要依赖过早返回的布尔值。