Golang错误处理如何影响单元测试编写

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 里封装好断言逻辑，比每次手写更可靠。