table-driven测试特别适合参数边界验证，因其用结构体切片统一管理输入、预期、错误标记等意图明确的字段，通过单循环驱动所有用例，避免重复代码并防止遗漏关键边界组合。
为什么 table-driven 测试特别适合参数边界验证
因为边界值（如空字符串、0、math.MaxInt64、nil）往往需要成组覆盖，而手动写多个 TestXxx 函数会导致重复逻辑和维护成本。table-driven 把输入、预期、描述打包成结构体切片，用一个循环驱动所有用例，既清晰又防遗漏。
定义边界测试表的典型结构
关键不是字段多，而是字段要能表达「输入意图」和「失败信号」。常见字段包括：name（可读性）、input（被测函数参数）、expected（期望返回值或错误）、shouldErr（布尔标记是否应出错）。
示例中避免用 int 作输入类型——它掩盖了边界语义；改用具体类型如 time.Duration 或自定义 type UserID int64，让边界更明确。
func TestParseUserID(t *testing.T) {
tests := []struct {
name string
input string
expected UserID
shouldErr bool
}{
{"empty string", "", 0, true},
{"negative number", "-123", 0, true},
{"zero", "0", 0, false},
{"max int64", "9223372036854775807", UserID(9223372036854775807), false},
{"overflow", "9223372036854775808", 0, true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := ParseUserID(tt.input)
if tt.shouldErr {
if err == nil {
t.Fatal("expected error, got nil")
}
return
}
if err != nil {
t.Fatalf("unexpected error: %v", err)
}
if got != tt.expected {
t.Errorf("ParseUserID(%q) = %v, want %v", tt.input, got, tt.expected)
}
})
}
}
容易忽略的边界组合与测试陷阱
单个参数的边界好列，但多个参数交叉时容易漏掉「合法输入的非法组合」。比如：start=5 和 end=3 对于区间函数是合法类型但非法语义。
立即学习“go语言免费学习笔记（深入）”；
-
t.Parallel()不要加在 table-driven 的外层循环里——它会让子测试并发执行，但共享变量（如循环变量tt）可能被复用，导致断言错乱；必须放在t.Run内部 - 用
t.Helper()标记辅助函数，否则错误行号会指向辅助函数而非测试用例内部 - 对浮点数边界，别用
==比较，改用assert.InDelta或手写误差容忍判断 - 如果被测函数接收指针或接口，边界值要考虑
nil输入——这常是 panic 来源
如何让边界表本身可维护、可扩展
把测试数据从代码里抽出来不现实（Go 不支持外部数据驱动），但可以分层：基础边界集 + 场景扩展集。例如先定义 basicBoundaries，再按业务场景叠加 apiV2EdgeCases。
更实用的是加注释字段 note，说明某个用例为何存在（如 "regression for CVE-2023-xxxx"），比靠记忆靠谱得多。
不要为每个边界写独立的 t.Run 名称——用 fmt.Sprintf 自动生成可读名，比如 fmt.Sprintf("input=%q/err=%t", tt.input, tt.shouldErr)，避免手写名称过长或重复。
边界测试不是越多越好，重点是覆盖「类型系统无法约束的语义边界」：负数、零、极大值、极小值、空、超长、编码异常（如 UTF-8 截断）、时区偏移等。其他情况交给 fuzzing 或集成测试。
