表驱动测试是Go官方推荐写法，因其契合“显式优于隐式”哲学：用[]struct{}+for range+t.Run集中声明用例、统一执行逻辑，无需框架或反射，支持精准失败定位、易扩展、语义化命名及并发安全。
表驱动测试为什么是Go官方推荐的写法
因为Go语言设计哲学强调“显式优于隐式”，而表驱动测试天然契合这一原则：它把所有用例数据集中声明、逻辑统一执行，不依赖框架或反射，也不需要额外DSL。它不是语法糖，而是用原生语法（[]struct{} + for range + t.Run）达成高可维护性的标准解法。
- 每个用例独立运行，失败时精准定位到
tt.name，而不是一堆TestFoo1/TestFoo2函数名 - 新增一个边界场景，只需往切片里加一行结构体，无需复制粘贴整个测试函数
- 结构体字段顺序（
name→input→expected→errWant）形成阅读直觉，团队协作时几乎不用解释 - Go 1.21+ 默认开启竞态检测，配合
tt := tt复制能避免闭包捕获循环变量的经典坑
如何正确写一个带error返回的表驱动测试
很多初学者在测func ParseInt(s string) (int, error)这类函数时，直接用err == tt.errWant判断，结果永远失败——因为错误值是接口，两个errors.New("x")不相等。
- 必须用
errors.Is(err, tt.errWant)或errors.As(err, &target)做语义比较 - 若需校验错误消息内容，用
assert.Equal(t, tt.errMsg, err.Error())，但优先用errors.Is（更健壮） -
errWant字段建议设为error类型而非string，保持类型一致性和可复用性 - 空错误场景别漏掉
nil：比如{"valid", "42", 42, nil}
什么时候不该用表驱动测试
不是所有测试都适合塞进一张表。当用例之间存在状态依赖、需要复杂setup/teardown、或单个用例逻辑远超其他用例时，强行表格化反而增加理解成本。
- 集成测试（如操作真实DB或HTTP服务）：更适合拆成独立
TestXXXIntegration函数，便于单独控制资源生命周期 - 基准测试（
BenchmarkXXX）：虽然也能表驱动，但必须用b.Run而非t.Run，且要严格分离初始化和计时区间（b.ResetTimer()位置错一点，ns/op就失真） - 测试逻辑差异大：比如一个用例要mock网络超时，另一个要验证重试策略，此时分拆更清晰
容易被忽略的细节：命名、并行与调试友好性
很多人写了表驱动，但失败日志还是难读，根源常在三个细节上。
立即学习“go语言免费学习笔记（深入）”；
-
t.Run的名称别偷懒写"test"，要用语义化名字，比如"empty_input_returns_error"，否则go test -v输出里全是TestFoo/test - 想并行？必须在
t.Run闭包开头立刻写t.Parallel()，且确保用例间无共享状态（比如全局map、文件句柄） - 断言失败时别只打
t.Errorf("got %v, want %v", got, want)，要带上上下文：t.Errorf("ParseURL(%q).Host = %q, want %q", tt.input, got.Host, tt.wantHost) - 复杂结构体比对别硬写
reflect.DeepEqual，配合cmp.Diff(got, want)能直接输出字段级差异，省去手写调试日志
