Go 表驱动测试组织多组输入输出

当一个函数需要覆盖空输入、边界值和正常值时，逐条复制测试函数很快会变成维护负担。Go 表驱动测试的核心做法，是把每组输入、期望输出和用例名称放进表格，再用 t.Run 为每一行建立子测试。这样既能复用测试逻辑，又能把失败定位到具体用例。

建议把“变化的数据”放进用例表，把“固定的判断逻辑”放进一次测试函数；每行用例使用稳定的 name，并在子测试内部完成调用和断言。

本文只讨论三件事：子测试如何组织、输入如何隔离、失败如何定位。示例使用标准库 testing，不依赖第三方断言库。

先看重复测试为什么难维护

假设要测试一个把字符串规范化的函数。最初可能只有一个正常输入，测试写起来很直观；后来补上空字符串、前后空格和大小写混合，常见做法是复制多个测试函数或在同一个函数里继续追加判断。

func TestNormalize(t *testing.T) {
	// 每个分支都重复调用和比较，新增用例会继续拉长函数。
	if got := normalize(" Go "); got != "go" {
		t.Errorf("normalize(Go) = %q; want %q", got, "go")
	}
	if got := normalize(""); got != "" {
		t.Errorf("normalize(empty) = %q; want empty", got)
	}
}

这种写法并非错误，但数据和流程混在一起：读者需要在多处寻找输入，失败日志也只能告诉你某个判断失败。只要把测试对象换成一个更复杂的返回结构，复制代码带来的噪声会更明显。

把多组输入输出提取成用例表

第一步只抽取数据，不急着引入并行或复杂断言。每个结构体字段都服务于一个明确问题：name 负责定位，input 是输入，want 是期望结果。

type normalizeCase struct {
	name  string
	input string
	want  string
}

func TestNormalize(t *testing.T) {
	tests := []normalizeCase{
		{name: "trim-and-lower", input: " Go ", want: "go"},
		{name: "empty-input", input: "", want: ""},
		{name: "mixed-case", input: "GoLang", want: "golang"},
	}

	_ = tests // 后续小节会在 t.Run 中消费这张表。
}

名称不要只写“case1”“case2”。它会出现在测试输出和 -run 过滤条件里，最好描述输入边界或业务意图。对于包含空格的名称，可以使用连字符或下划线，让命令行过滤更稳定。

用 t.Run 为每一行建立子测试

testing.T.Run 接收名称和一个子测试函数。官方文档说明，子测试拥有自己的 *testing.T，父测试会等待子测试结束；这正好适合表驱动测试的“一行一组输入输出”结构。

func TestNormalize(t *testing.T) {
	tests := []normalizeCase{
		{name: "trim-and-lower", input: " Go ", want: "go"},
		{name: "empty-input", input: "", want: ""},
		{name: "mixed-case", input: "GoLang", want: "golang"},
	}

	for _, tt := range tests {
		// 将当前用例绑定给闭包，避免后续增加并行测试时误用循环变量。
		tt := tt
		t.Run(tt.name, func(t *testing.T) {
			got := normalize(tt.input)
			if got != tt.want {
				t.Errorf("normalize(%q) = %q; want %q", tt.input, got, tt.want)
			}
		})
	}
}

这里的固定流程只有一份：取当前输入、调用函数、比较结果。每个子测试通过 tt.name 区分，失败日志可以直接指向 TestNormalize/trim-and-lower 这样的路径。图1把测试表、t.Run、testing.T 和断言之间的静态关系画在一起，便于理解数据字段与测试上下文各自的职责。

为什么要显式隔离输入

表驱动测试最容易被忽视的问题不是表格本身，而是用例之间是否共享可变数据。如果输入是切片、映射或指针，测试函数修改它，就可能把前一个用例的状态带到下一个用例。

type sortCase struct {
	name  string
	input []int
	want  []int
}

func TestSortCopy(t *testing.T) {
	tests := []sortCase{
		{name: "unsorted", input: []int{3, 1, 2}, want: []int{1, 2, 3}},
		{name: "already-sorted", input: []int{1, 2, 3}, want: []int{1, 2, 3}},
	}

	for _, tt := range tests {
		tt := tt
		t.Run(tt.name, func(t *testing.T) {
			// 复制切片，避免被测函数原地修改测试表里的底层数组。
			input := append([]int(nil), tt.input...)
			got := sortCopy(input)
			if !slices.Equal(got, tt.want) {
				t.Errorf("sortCopy(%v) = %v; want %v", tt.input, got, tt.want)
			}
		})
	}
}

隔离策略取决于数据类型：字符串和整数通常可以直接复制；切片要考虑底层数组；映射可以用新映射复制键值；指针则要明确被测函数是否允许修改它指向的对象。不要为了“表驱动”而强行复制所有数据，先确认被测函数的所有权约定。

让失败信息落到具体用例

断言最好放在子测试内部，并在错误信息里同时保留输入、实际值和期望值。t.Errorf 会记录格式化信息并标记当前测试失败，但不会立即终止子测试；如果后面还有互相独立的断言，可以继续收集信息。

func TestParsePort(t *testing.T) {
	tests := []struct {
		name  string
		input string
		want  int
		err   bool
	}{
		{name: "valid", input: "8080", want: 8080},
		{name: "invalid-text", input: "http", err: true},
	}

	for _, tt := range tests {
		tt := tt
		t.Run(tt.name, func(t *testing.T) {
			got, err := parsePort(tt.input)
			if (err != nil) != tt.err {
				// 错误状态与期望不一致时，先报告输入和错误状态。
				t.Errorf("parsePort(%q) error = %v; want error %v", tt.input, err, tt.err)
				return
			}
			if !tt.err && got != tt.want {
				t.Errorf("parsePort(%q) = %d; want %d", tt.input, got, tt.want)
			}
		})
	}
}

如果断言依赖前一个断言的结果，可以在失败后 return，避免继续使用不完整数据。若必须终止当前子测试，可以使用 t.Fatalf；不要在测试启动的其他 goroutine 中调用 FailNow 或 Fatalf，因为这类终止方法必须运行在测试函数所在的 goroutine。

兼容注意：循环变量、并行和测试名称

保留当前用例绑定

即使当前测试没有调用 t.Parallel，也建议在循环体里写 tt := tt，或者把当前值作为参数传给闭包。这样代码在未来改成并行子测试时，输入隔离意图不会被遗忘。

并行不是表驱动测试的默认项

t.Parallel 会改变资源访问约束。只有当用例之间不共享环境变量、临时文件、全局状态或可变对象时，才适合在子测试中启用它；并行化前先把输入和清理边界讲清楚。

名称是回归入口的一部分

测试名称既是阅读信息，也是筛选入口。可以用下面的命令只运行父测试下名称包含 invalid 的用例：

# -run 使用正则筛选测试名，斜杠用于匹配父测试和子测试层级。
go test ./... -run 'TestParsePort/invalid'

如果名称来自外部输入，先做稳定的规范化，避免空格、斜杠和不可见字符让筛选条件难以复用。

一张表判断是否适合这样组织

总结

Go 表驱动测试不是把数据塞进一个切片就结束了。更稳妥的组织方式是：用结构体切片表达输入输出，用稳定的 name 表达问题边界，用 t.Run 建立独立子测试，在子测试内完成调用和断言；遇到切片、映射、指针或并行场景，再按所有权和清理边界处理隔离。

常见问题

表驱动测试必须使用 t.Run 吗？

不是。只有一组简单判断时，普通测试函数就足够；当你需要独立名称、单独筛选或更清晰的失败归属时，使用 t.Run 更合适。

为什么每次循环都写 tt := tt？

它把当前行绑定到闭包变量，提前表达输入隔离意图，尤其适合后续加入 t.Parallel 或异步逻辑的测试。

子测试失败后父测试会继续吗？

通常会继续处理其它子测试，最终父测试会根据子测试结果反映失败。若当前子测试后续逻辑依赖已经失败的前置条件，可以在子测试内部 return 或使用 Fatalf。

错误信息应该写哪些字段？

至少包含输入、实际值和期望值；如果错误状态也是结果的一部分，还要同时说明是否期望有 error。