Go测试中如何使用table driven_Go表驱动测试写法

table-driven测试是Go中通过结构体切片定义测试用例、用for循环配合t.Run执行的参数化测试模式，核心是数据驱动逻辑，提升可读性、可扩展性与可维护性。

Go测试中如何使用table driven_Go表驱动测试写法第1张

什么是 table-driven 测试

Go 语言中没有内置的参数化测试机制，table-driven 是社区约定俗成的写法：把输入、期望输出、描述等组织成一个结构体切片，用 for 循环遍历执行断言。它不是语法特性，而是一种模式——核心是“数据驱动逻辑”，让测试更易读、易扩、易维护。

基础写法：定义 test case 结构体 + range 循环

最简形式就是声明一个 []struct{}，字段按需包含 name（用于 t.Run）、输入参数、期望结果、是否应 panic 等。关键点在于每个 case 独立运行，失败时能精准定位到哪个 name。

func TestAdd(t *testing.T) {
	cases := []struct {
		name     string
		a, b     int
		expected int
	}{
		{"positive", 2, 3, 5},
		{"negative", -1, -2, -3},
		{"zero", 0, 0, 0},
	}
	for _, tc := range cases {
		t.Run(tc.name, func(t *testing.T) {
			got := Add(tc.a, tc.b)
			if got != tc.expected {
				t.Errorf("Add(%d,%d) = %d, want %d", tc.a, tc.b, got, tc.expected)
			}
		})
	}
}

t.Run 必须在循环内调用，否则所有 case 共享同一个 t 上下文，无法并行或独立失败
结构体字段名建议小写（如 name），避免暴露给包外；但只要在测试文件内，大小写不影响使用
不要在循环里用 range 的索引变量做闭包捕获（比如 go func() { cases[i] }()），会因变量复用导致数据错乱

处理 error 和 panic 场景

真实函数常返回 error 或可能 panic，这时 test case 需增加对应字段，并在循环体内显式检查。尤其注意 panic 捕获必须用 recover() + defer 组合，且只能在当前 goroutine 生效。

func TestParseInt(t *testing.T) {
	cases := []struct {
		name        string
		input       string
		expected    int
		expectError bool
	}{
		{"valid", "42", 42, false},
		{"invalid", "abc", 0, true},
	}
	for _, tc := range cases {
		t.Run(tc.name, func(t *testing.T) {
			got, err := strconv.Atoi(tc.input)
			if tc.expectError {
				if err == nil {
					t.Error("expected error but got nil")
				}
				return
			}
			if err != nil {
				t.Fatalf("unexpected error: %v", err)
			}
			if got != tc.expected {
				t.Errorf("got %d, want %d", got, tc.expected)
			}
		})
	}
}

用 expectError bool 控制校验方向，比反复判断 err != nil 更清晰
对 panic 场景，可加 shouldPanic bool 字段，然后在循环内写 defer func() { if r := recover(); r == nil && tc.shouldPanic { t.Fatal("expected panic") } }()
避免在 t.Run 内部直接调用可能 panic 的函数而不 recover，否则整个子测试会中断，后续 case 不再执行

进阶技巧：共享 setup / teardown 和 benchmark 复用

有些测试需要共用资源（如临时文件、mock DB 连接），可在循环外做一次 setup，但要注意并发安全；若用 t.Parallel()，则每个 t.Run 必须有自己隔离的资源。另外，benchmarks 也能用 table-driven，只是用 b.Run 替代 t.Run。