表格驱动测试的核心价值是分离测试逻辑与数据，需严格定义name、输入、预期三类字段，避免循环变量复用、类型不安全及不可靠计算，且不适用于高成本setup/teardown场景。
为什么表格驱动测试不是“多写几个 test case”那么简单
表格驱动测试的核心价值，不是让测试代码看起来更整齐，而是把「测试逻辑」和「测试数据」彻底分离。很多人直接照搬示例，用 struct{input, want string} 包一堆数据，结果一加新字段就漏改 for 循环里的赋值，或者忘记给某个 case 补 name 字段导致 t.Run 报空指针。
真正起作用的结构体必须包含三类字段：name（用于 t.Run 显示）、输入参数（按函数签名对齐）、预期输出（含 error 判断）。别图省事塞 map 或 interface{}——类型安全在测试里一样重要。
-
name必须唯一且可读，比如"ParseDuration_2h_returns_7200"，别用"case1" - 每个字段名要跟被测函数参数/返回值语义一致，比如函数返回
(int, error)，结构体就该有expectedN int和expectedErr bool，而不是笼统的want - 避免在 table 里做计算或调用函数（如
time.Now()），否则测试不可靠；时间相关 case 应该用固定字符串或time.Date(2000, 1, 1, ...)
怎么写一个能扛住重构的测试表
当被测函数签名变了、新增参数、返回值拆包，最怕改完函数发现所有 table 测试都 panic。关键是在 table 定义时就预留扩展性，而不是硬编码字段顺序。
推荐用具名字段 + 零值默认策略。例如被测函数是 func FormatName(first, last string, opts ...FormatOption) string，table 结构体就该显式声明 first, last string 和 opts []FormatOption，哪怕某条 case 不传 opts，也写成 opts: nil，而不是省略字段靠位置推断。
立即学习“go语言免费学习笔记（深入）”；
- 所有字段必须显式初始化，禁止依赖 struct 字面量的字段省略（除非明确想用零值）
- 如果多个 case 共享同一组选项，抽成常量：
var withUpper = []FormatOption{Upper()}，别重复写[]FormatOption{Upper()} - error 检查别只比对
err != nil，要用errors.Is(err, expectedErr)或strings.Contains(err.Error(), "xxx")，否则底层 error 类型一换就挂
常见 panic 场景和对应 fix
运行表格测试时突然 panic，90% 出现在 t.Run 内部，但错误堆栈指向 table 外层。这是因为 Go 的 range 循环变量复用导致闭包捕获的是最后一个值。
典型错误写法：for _, tc := range tests { t.Run(tc.name, func(t *testing.T) { ... use tc ... }) } —— 看似没问题，实际所有子测试都用的是循环末尾的 tc。
- 必须用局部变量拷贝：
for _, tc := range tests { tc := tc; t.Run(tc.name, func(t *testing.T) { ... }) } - 如果 table 数据量大（>100 条），记得在
t.Parallel()前确认被测函数是否线程安全；带全局状态（如修改包级变量、重置 time.Now）的函数不能并行 - 遇到
panic: test executed panic with value [recovered]，先检查 table 里有没有故意传nil指针进去又没提前 guard，比如传(*bytes.Buffer)(nil)给需要写入的函数
什么时候不该用表格驱动
不是所有测试都适合表格化。当 setup 成本高（比如要启 HTTP server、建临时 DB）、teardown 逻辑复杂（清理资源失败会影响后续 case），或者单个 case 需要定制大量前置条件时，硬套表格只会让代码更难懂、更难 debug。
典型反例：测试一个依赖外部 API 的客户端方法。你不可能把 10 个不同 HTTP 状态码、不同响应 body 的 case 全塞进一张表里，然后共享同一个 mock server 启停逻辑。
- setup/teardown 超过 3 行代码 → 单独写 test function
- 某个 case 需要 sleep 或等待异步完成 → 别混进表格，单独处理超时和重试
- 测试目标是验证 panic 行为（比如
recover()逻辑），用defer+recover()显式检查比表格更清晰
表格驱动的价值，在于让「相同逻辑、不同输入」的验证变得可维护。一旦输入差异开始影响执行路径本身，就该收手了。
