table-driven测试是将输入、期望输出和描述封装为结构体切片并用for循环执行的Go测试模式，它通过自包含的边界值条目（如空字符串、0、math.MaxInt64、nil）提升边界条件验证的可维护性与可读性。
什么是 table-driven 测试，为什么它适合边界条件验证
Go 语言中，table-driven test 不是一种框架，而是一种组织测试用例的惯用模式：把输入、期望输出、可选的描述打包成结构体切片，再用一个 for 循环统一执行断言。它特别适合边界测试，因为边界值（如空字符串、0、math.MaxInt64、nil）往往成组出现，手动写多个 TestXxx 函数既重复又难维护。
如何构造边界测试表：字段选哪些、怎么命名
一个清晰的测试表至少包含三个字段：name（用于 t.Run() 的子测试名）、input（传给被测函数的参数）、want（期望返回值）。如果函数有多个参数或返回多个值，建议用结构体封装输入和输出，避免位置错乱。
常见错误是把边界值硬编码在循环体里——这会让测试难以快速定位问题。正确做法是让每个 test 条目自包含：
func TestParsePort(t *testing.T) {
tests := []struct {
name string
input string
want int
wantErr bool
}{
{"empty string", "", 0, true},
{"zero", "0", 0, false},
{"negative", "-1", 0, true},
{"too large", "65536", 0, true},
{"valid max", "65535", 65535, false},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := ParsePort(tt.input)
if (err != nil) != tt.wantErr {
t.Errorf("ParsePort() error = %v, wantErr %v", err, tt.wantErr)
return
}
if !tt.wantErr && got != tt.want {
t.Errorf("ParsePort() = %v, want %v", got, tt.want)
}
})
}
}
边界测试容易漏掉的几类值
只测 0 和 1 不够。真实边界常藏在类型定义或业务规则里：
立即学习“go语言免费学习笔记（深入）”；
-
int类型：除了0，必须覆盖math.MinInt64、math.MaxInt64、-1（尤其当函数做n-1运算时） -
string：空串""、单字符"a"、超长字符串（比如strings.Repeat("x", 1000000)）、含 Unicode 或控制字符（如"\x00"） -
[]byte或slice：nil 切片（nil）、零长切片（[]int{}），二者行为可能不同 -
time.Time：time.Time{}（零值）、time.Unix(0, 0)、极远未来/过去时间
性能与可读性的平衡点在哪里
边界测试不是越多越好。100 个随机生成的“大数”不如 3 个明确的临界点（65535、65536、65537）有用。重点在于每个测试用例都**有明确意图**：它是为验证溢出？空值处理？还是协议规定的保留值？
如果某个边界逻辑复杂（比如多条件组合判断），宁可拆成多个独立的 TestXxx 函数，也不要在一个 table 中堆砌模糊的 name 描述。Go 的测试运行器对子测试名非常敏感——t.Run("when input is negative and length > 10", ...) 比 t.Run("edge case 7", ...) 容易 debug 得多。
真正麻烦的是那些隐式边界：比如函数内部调用了 json.Unmarshal，那就要额外加 ""、"null"、"{}"、"[]" 等 JSON 边界输入——这些不会出现在函数签名里，但会直接导致 panic 或静默失败。
