table-driven 测试写法模板（面试常考）

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 做无效断言（比如 nil duration）

什么时候该加 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 字段背后。