table-driven测试的本质是将输入、预期输出、辅助条件等统一放入切片，用for循环驱动执行；它强调结构化表达多组边界case，核心在于清晰、可扩、易定位失败用例。
什么是 table-driven 测试的本质
它不是语法糖，而是一种组织测试用例的模式：把输入、预期输出、辅助条件（如是否应 panic）统一放进一个切片里，再用 for 循环驱动每个用例执行。Go 官方文档和标准库大量使用这种写法，面试官看的不是你会不会写 for range，而是你能否自然地把“多组边界 case”结构化表达出来。
最简可用模板（带错误处理场景）
别一上来就加注释字段或子测试名——先保证能跑通、易读、易扩。以下是最小闭环：
func TestParseDuration(t *testing.T) {
tests := []struct {
input string
expected time.Duration
wantErr bool
}{
{"1s", time.Second, false},
{"0", 0, false},
{"", 0, true},
{"-5s", 0, true},
}
for _, tt := range tests {
t.Run(fmt.Sprintf("ParseDuration(%q)", tt.input), func(t *testing.T) {
got, err := time.ParseDuration(tt.input)
if (err != nil) != tt.wantErr {
t.Fatalf("ParseDuration(%q) error = %v, wantErr %v", tt.input, err, tt.wantErr)
}
if !tt.wantErr && got != tt.expected {
t.Errorf("ParseDuration(%q) = %v, want %v", tt.input, got, tt.expected)
}
})
}
}
关键点：
-
t.Run必须用，否则失败时无法定位是哪个 case 崩了 -
if (err != nil) != tt.wantErr是惯用判错方式，比if tt.wantErr && err == nil更对称、不易漏分支 - 只在
!tt.wantErr时比较结果值，避免对got做无效断言（比如nilduration）
什么时候该加 name 字段？
当用例逻辑开始分组、有语义差异时，比如 “正数输入”、“负数输入”、“含单位缩写”、“空格干扰”。此时靠 fmt.Sprintf 拼名字会模糊重点，建议显式加字段：
tests := []struct {
name string
input string
expected int
wantErr bool
}{
{"positive", "42", 42, false},
{"negative", "-7", -7, false},
{"leading_space", " 123", 123, false},
{"empty", "", 0, true},
}
然后 t.Run(tt.name, ...)。注意：name 不是装饰，它是调试时第一眼看到的上下文——如果写成 "case 3" 或留空，等于放弃这个优势。
容易被忽略的陷阱
table-driven 测试最难的不是写法，而是“哪些变量该进表、哪些不该”。常见翻车点：
- 把测试中需要复用的 setup/teardown 逻辑硬塞进每个 struct 里（比如打开文件、启动 mock server），导致用例耦合、难维护 → 应提成独立函数，在循环内调用
- 用
range遍历时直接传&tt给 goroutine（哪怕没显式起 goroutine），造成所有 case 共享最后一个tt的地址 → 必须在循环体内定义新变量：tt := tt - 把
expected设为指针或复杂结构体但没实现DeepEqual安全比较，或误用==比较 slice/map → 要么用reflect.DeepEqual，要么确保类型支持可比性
真正写得好的 table-driven 测试，case 表本身应该像单元格一样干净，所有“动起来”的东西都在循环体里，而不是藏在 struct 字段背后。
