Go单元测试必须显式检查error返回值,覆盖err!=nil分支,优先用errors.Is或assert.ErrorIs判断错误语义,避免字符串比较;表驱动测试中应使用wantErr error字段而非bool,并注意错误包装与可比性。
error 返回值Go 的错误处理是显式的,error 是函数返回值的一部分,不是异常。这意味着在单元测试中,你不能靠 panic 捕获或忽略它——不检查 err != nil 就等于漏测失败路径。
常见错误现象:测试只验证正常输出,却对 err 置之不理,导致逻辑错误(如文件未创建、DB 查询失败)在测试中完全隐身。
error 返回的被测函数,测试用例必须覆盖 err != nil 分支if err != nil { t.Fatal(err) } 一棍子打死——这会掩盖真实错误类型和上下文assert.ErrorIs(t, err, fs.ErrNotExist)(需 testify)或原生 errors.Is(err, fs.ErrNotExist) 做语义判断error 类型来驱动边界测试真实依赖(如 HTTP 客户端、数据库驱动)往往返回特定错误(如 net.ErrClosed、sql.ErrNoRows),而这些错误常被上层逻辑分支处理。单元测试要复现它们,不能只用 errors.New("mock")。
使用场景:测试一个重试逻辑是否在遇到 context.DeadlineExceeded 时退出,或是否对 sql.ErrNoRows 返回空结果而非 panic。
errors.Join() 或 fmt.Errorf("wrap: %w", originalErr) 保留原始错误类型,便于 errors.Is() 判断err.Error() == "connection refused" —— 脆弱且不可靠io.EOF、os.ErrPermission);对自定义错误,导出变量(如 var ErrInvalidID = errors.New("invalid id"))供测试引用defer + recover 在 Go 测试中基本无用Go 不鼓励用 panic 处理业务错误,因此绝大多数单元测试不需要、也不应该用 recover 捕获 panic。误用反而掩盖设计问题。
只有极少数场景适用:测试某个函数**明确要求 panic**(如 sync.Pool.Get 对非法参数 panic),或验证第三方库的 panic 行为。
defer func() { recover() }() —— 这会让 panic 静默失败,失去调试线索go test 自动标记失败并打印堆栈
assert.Panics(t, func() { f() })(testify)或手动 defer/recover 并校验 panic 值表驱动测试(table-driven tests)很适合覆盖多组输入/输出,但新手常把 error 判断写死在循环外,或只给一个 wantErr bool 而不指定
具体错误类型。
func TestParseInt(t *testing.T) {
tests := []struct {
name string
input string
want int
wantErr bool // ❌ 太粗粒度:无法区分 fs.ErrNotExist 和 strconv.ErrSyntax
}{
{"empty", "", 0, true},
{"invalid", "abc", 0, true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := strconv.Atoi(tt.input)
if (err != nil) != tt.wantErr {
t.Errorf("ParseInt() error = %v, wantErr %v", err, tt.wantErr)
return
}
if !tt.wantErr && got != tt.want {
t.Errorf("ParseInt() = %v, want %v", got, tt.want)
}
})
}
}
wantErr 拆成 wantErr error 字段,用 errors.Is(err, tt.wantErr) 校验var nilError error 显式声明,避免 nil 字面量歧义// expect io.EOF when reader hits end)errors.Is 和 errors.As 是绕不开的,但很多人直到测试失败才去查文档——提前在测试 helper 里封装好断言逻辑,比每次手写更可靠。