table-driven测试是Go中通过结构体切片定义测试用例、用for循环配合t.Run执行的参数化测试模式，核心是数据驱动逻辑，提升可读性、可扩展性与可维护性。
什么是 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。
- setup 放在
for外，teardown 用defer在测试函数末尾执行（适用于全局只初始化一次的场景） - 若每个 case 需独立资源（如不同数据库事务），就把初始化逻辑放进
t.Run内部 - benchmark 表驱动时，注意
b.ResetTimer()位置：应在 setup 完成后、实际被测函数调用前调用 - 别把大量预计算数据（如 10MB JSON 样本）塞进 test case 结构体，应懒加载或从文件读取，避免编译慢和内存占用高
