Go单元测试如何处理异常\_错误场景测试技巧

Go单元测试中处理错误和panic需遵循其独特机制：不能使用try/catch，而应通过defer+recover在同goroutine内精准捕获panic，并借助testify/assert等工具校验panic值；但更推荐函数返回error而非panic，以实现更直观、稳定、符合Go惯用法的测试——直接检查err、用errors.Is/As做类型与语义判断；尤其要注意并发场景下goroutine内的panic无法被主goroutine recover，必须通过重构（如错误回传channel）来保障可测性与健壮性。

Go 单元测试中如何断言 panic 发生

Go 没有传统意义上的“异常抛出/捕获”机制，panic 是运行时崩溃信号，不能用 try/catch 捕获。要测试函数是否按预期 panic，必须用 recover 配合 defer 在子 goroutine 或封闭作用域中拦截。

常见错误是直接调用被测函数后写 if err != nil —— 这对 panic 完全无效，程序会直接终止。

• 必须在 defer 中调用 recover()，且该 defer 必须在 panic 触发前已注册
• 推荐将待测逻辑封装进匿名函数，再用 func() { ... }() 调用，避免污染外部测试流程
• 不要在测试函数顶层 defer —— 它会在测试结束时才执行，起不到捕获作用

func TestDivideByZeroPanic(t *testing.T) {
	defer func() {
		if r := recover(); r == nil {
			t.Fatal("expected panic but none occurred")
		}
	}()

	divide(10, 0) // 假设这个函数内部 panic("division by zero")
}

使用 testify/assert 匹配 panic 内容

原生 testing 包只能判断 panic 是否发生，无法校验 panic 的值（比如字符串消息或自定义 error 类型）。此时需要手动解包 recover() 返回值，或借助 testify/assert 的 PanicsWithValue / PanicsWithError。

注意：testify/assert 的 panic 断言底层仍是基于 recover 封装，所以同样要求被测代码在当前 goroutine 中 panic。

• PanicsWithValue(t, func() { f() }, "invalid input")：匹配 panic 值的 == 相等性（适用于字符串、int 等可比较类型）
• PanicsWithError(t, "EOF", func() { f() })：只匹配 panic 值的 Error() 方法返回字符串（适用于 error 类型）
• 若 panic 的是自定义结构体且未实现 Error()，需用 PanicsWithValue 并确保该结构体可比较

import "github.com/stretchr/testify/assert"

func TestParseJSONPanic(t *testing.T) {
	assert.PanicsWithValue(t, "invalid character", func() {
		parseJSON([]byte("{ invalid }"))
	})
}

测试 error 返回路径比 panic 更推荐

除非业务逻辑明确要求崩溃（如初始化失败、配置不可恢复错误），否则应优先让函数返回 error 而非触发 panic。这使得测试更直观、可控，也符合 Go 的惯用法（“don’t panic”）。

返回 error 的函数可直接用常规方式验证：

• 检查 err 是否为 nil
• 用 errors.Is() 判断是否为特定错误（如 io.EOF）
• 用 errors.As() 提取自定义错误类型进行字段校验
• 避免用 err.Error() == "xxx" 做字符串匹配 —— 易受格式变更影响

func TestOpenFileNotFound(t *testing.T) {
	_, err := os.Open("/nonexistent/file.txt")
	if !os.IsNotExist(err) {
		t.Fatalf("expected file not found error, got %v", err)
	}
}

并发场景下 panic 测试的陷阱

如果被测函数在 goroutine 中 panic（例如启动一个异步任务后内部 panic），主 goroutine 不会感知，测试会超时或直接通过 —— 因为 panic 发生在子 goroutine，而 recover 只能捕获当前 goroutine 的 panic。

这种情况下无法用常规方式断言，必须重构代码：要么把 panic 逻辑移到主流程，要么改用 channel + context 控制生命周期，并让错误通过 channel 返回。

• 绝对不要依赖 “goroutine 中 panic 后主线程能 recover” —— 这是常见误解
• 若必须保留 goroutine 内 panic，可在其内部加日志或发送信号到 channel，再由测试等待该信号
• 更稳妥的做法是：禁止业务代码在 goroutine 中 panic，统一转为 return err 或向 channel 发送 error

终于介绍完啦！小伙伴们，这篇关于《Go单元测试如何处理异常\_错误场景测试技巧》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！