边界条件测试应覆盖0、1、65535、65536等临界值，有符号整型极值，浮点数±0.0和NaN，切片首末及越界索引；需用table-driven test显式声明输入与期望，并手动验证所有分支，包括panic场景。
边界条件测试该覆盖哪些值
Go 的 testing 包本身不强制边界检查，但实际写测试时漏掉边界值是覆盖率虚高的主因。比如一个解析端口号的函数，只测 80 和 8080 没用，必须覆盖 0、1、65535、65536 这类临界点。
常见错误现象：测试跑过，但上线后遇到 0 或负数输入 panic，日志里只显示 index out of range，根本看不出是哪条分支没走。
-
0（空、最小合法值、切片首索引） -
len(s) - 1和len(s)（切片末尾与越界） - 有符号整型的
math.MinInt32/math.MaxInt32（尤其做加减运算前） - 浮点数的
+0.0、-0.0、NaN（==判定会失效）
用 table-driven test 写边界用例更稳
硬写一堆 if 分支测试容易漏，也难维护。Go 社区惯用结构体切片 + range 驱动，把输入、期望、是否应 panic 全部显式声明。
性能影响几乎为零，但能显著降低新增边界 case 时的出错概率——尤其是多人协作改同一函数时。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个 test case 用匿名 struct 定义，字段名要见名知意，比如
input、expectedErr、wantPanic - 在
for _, tc := range tests循环开头加t.Run(fmt.Sprintf("%v", tc.input), func(t *testing.T) { ... })，失败时能快速定位是哪个输入崩了 - 不要复用变量名如
test，避免嵌套循环中作用域污染；用tc（test case 缩写）更安全
示例：
tests := []struct {
input int
expected string
}{
{0, "zero"},
{1, "one"},
{65535, "max"},
}
for _, tc := range tests {
t.Run(fmt.Sprintf("input=%d", tc.input), func(t *testing.T) {
got := parsePort(tc.input)
if got != tc.expected {
t.Errorf("parsePort(%d) = %q, want %q", tc.input, got, tc.expected)
}
})
}
覆盖率工具对边界测试的“盲区”
go test -cover 只统计语句是否执行过，不保证分支逻辑被充分验证。一个 if x > 0 { A() } else { B() }，哪怕只测了 x=1，覆盖率也显示 100%，但 x=-1 对应的 B() 根本没触发。
这导致团队误以为“覆盖率 90% 就够了”，结果线上 else 分支第一次执行就 panic。
- 用
go tool cover -func查看具体函数的行覆盖，重点盯if、switch、for的条件分支行 - 对关键判断逻辑，手动补全所有分支输入：比如
switch v := x.(type)，必须覆盖每种type，包括nil - 别信 IDE 插件标绿的行——它只告诉你“这行执行了”，没告诉你“所有分支都走了”
panic 场景的测试必须显式捕获
Go 里用 panic 表达非法状态很常见，但直接调用会中断整个测试函数。不处理的话，一次 panic 就让后续所有用例跳过，你还以为是环境问题。
正确做法是用 recover 搭配 defer 捕获，再比对 panic 值。标准库 testing 不提供封装，得自己写薄层。
- 写一个通用辅助函数
mustPanic，接收函数并返回recover()结果，避免每个测试都重复写defer块 - 注意：不能在子 goroutine 里 panic 后 recover，Go 的
recover只对当前 goroutine 有效 - 如果函数既可能正常返回又可能 panic，测试里要分别写两个 case，不能合并断言
示例：
func mustPanic(f func()) (r interface{}) {
defer func() { r = recover() }()
f()
return nil
}
// 使用
if mustPanic(func() { parsePort(-1) }) == nil {
t.Error("expected panic for negative port")
}
边界测试最难的不是写法，而是想全——人容易忽略“那个值真的不会出现吗”，而生产环境总在你没测的地方出问题。
