Go单元测试必须显式检查error返回值，覆盖err!=nil分支，优先用errors.Is或assert.ErrorIs判断错误语义，避免字符串比较；表驱动测试中应使用wantErr error字段而非bool，并注意错误包装与可比性。
Go 单元测试必须显式检查 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。
立即学习“go语言免费学习笔记（深入）”；
- 用
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 静默失败，失去调试线索 - 若被测代码意外 panic，应让它冒泡，由
go test自动标记失败并打印堆栈 - 真要测 panic，用
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)校验 - 对 nil 错误，用
var nilError error显式声明，避免nil字面量歧义 - 测试数据里加入注释说明为何该 case 应返回特定错误（例如：
// expect io.EOF when reader hits end）
errors.Is 和 errors.As 是绕不开的，但很多人直到测试失败才去查文档——提前在测试 helper 里封装好断言逻辑，比每次手写更可靠。 
