核心思路是利用defer中的recover捕获panic，将程序中断事件转化为可断言的测试结果。通过在defer函数中调用recover()，能捕获预期panic并验证其值，确保测试流程可控，避免程序崩溃，从而在测试中准确验证panic行为。
在Golang中测试
panic行为，并利用
recover进行捕获验证，其核心思路是借助
defer语句在预期会发生
panic的代码执行后，检查是否成功捕获到
panic。这允许我们把原本会导致程序中断的
panic转化为一个可检测的事件，从而在测试框架内对其进行断言。
解决方案
要测试一个函数在特定条件下是否会
panic，我们通常会这样组织测试代码：
- 定义一个
defer
函数，它会在外部函数返回前执行。 - 在这个
defer
函数内部，调用recover()
。如果recover()
返回非nil
值，说明发生了panic
。 - 根据
recover()
返回的值，我们可以判断panic
是否符合预期，并进行相应的断言。 - 最后，在
defer
函数之后，调用那个我们期望它会panic
的函数。
下面是一个具体的例子：
package main
import (
"fmt"
"testing"
)
// SomeFunction 模拟一个在特定条件下会panic的函数
func SomeFunction(input int) {
if input < 0 {
panic("input cannot be negative")
}
if input == 0 {
panic(fmt.Errorf("zero is not allowed"))
}
fmt.Println("Processing input:", input)
}
func TestSomeFunctionPanics(t *testing.T) {
tests := []struct {
name string
input int
expectedMsg string // 期望的panic消息
expectPanic bool
}{
{
name: "Negative input panics with string",
input: -1,
expectedMsg: "input cannot be negative",
expectPanic: true,
},
{
name: "Zero input panics with error",
input: 0,
expectedMsg: "zero is not allowed",
expectPanic: true,
},
{
name: "Positive input does not panic",
input: 10,
expectPanic: false,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
// 设置一个defer函数来捕获panic
defer func() {
if r := recover(); r != nil {
// 捕获到panic
if !tt.expectPanic {
t.Errorf("Expected no panic, but got panic: %v", r)
return
}
// 检查panic消息是否符合预期
switch v := r.(type) {
case string:
if v != tt.expectedMsg {
t.Errorf("Panic message mismatch. Got '%s', want '%s'", v, tt.expectedMsg)
}
case error:
if v.Error() != tt.expectedMsg {
t.Errorf("Panic error message mismatch. Got '%s', want '%s'", v.Error(), tt.expectedMsg)
}
default:
t.Errorf("Unknown panic type: %T, value: %v", v, v)
}
return // 确保捕获到panic后不再执行后续的检查
}
// 没有捕获到panic
if tt.expectPanic {
t.Errorf("Expected panic, but got none")
}
}()
// 调用可能panic的函数
SomeFunction(tt.input)
})
}
}
为什么直接测试panic
会失败？recover
在测试中的作用是什么？
我们都知道，Go语言中的
panic，如果不在当前Goroutine中被
recover捕获，那它就会一路向上冒泡，直到程序崩溃。在
testing包的语境下，如果一个测试函数内部发生了未被
recover的
panic，测试运行器通常会直接中断当前测试的执行，并标记为失败，甚至可能导致整个测试进程的崩溃。这并不是我们想要的“测试通过”或“测试失败”的明确结果，而是一种非预期的中断。
立即学习“go语言免费学习笔记（深入）”；
直接调用一个会
panic的函数，然后期望
testing.T能自动捕获并报告，这是不现实的。
testing.T本身并没有内置这种捕获
panic并进行断言的能力。它只能处理常规的错误（比如通过
t.Errorf或
t.Fatal报告）。
这时候，
recover就成了我们的救星。它就像一个安全网，部署在
defer函数里，专门用来接住那些从天而降的
panic。当
panic发生时，
recover会捕获到
panic的值，并允许程序继续执行，而不是直接崩溃。在测试中，这意味着我们可以在
recover之后，对捕获到的
panic值进行检查，比如它的类型、它的消息内容，从而验证我们的代码是否如预期那样在特定条件下
panic了。它将一个破坏性的运行时事件，转化为了一个可以编程检查的返回值，这对于测试那些设计上就预期会
panic的边缘情况至关重要。
编写可测试的panic
场景有什么技巧？
要让
panic行为变得可测试，并不仅仅是知道
defer和
recover的用法那么简单，还需要一些设计上的考量。
首先，让panic
的触发条件明确且可控。如果你的函数
panic是因为某个外部服务不可用，那测试起来就麻烦了。理想情况下，
panic应该是由函数参数、内部状态或可模拟的依赖行为触发的。例如，我们上面
SomeFunction的例子，
panic的触发完全依赖于输入的整数值，这非常容易在测试中复现。
其次，让panic
携带明确的信息。
panic可以接受任何类型的值作为参数。可以是简单的字符串，也可以是
error类型，甚至是自定义的结构体。我个人倾向于使用
fmt.Errorf来创建
error类型的
panic，因为这样可以包含更丰富的上下文信息，并且后续在
recover时可以方便地通过
error接口来处理。例如，
panic(fmt.Errorf("invalid config: missing %s", key))就比panic("bad config")提供了更多有用的信息，这在断言panic的具体原因时非常有帮助。
再者，隔离panic
源。在测试中，我们希望验证的是特定函数在特定条件下的
panic行为，而不是其内部调用的某个辅助函数。如果你的函数A调用了函数B，而函数B可能
panic，那么在测试函数A时，你可能需要模拟或控制函数B的行为，以确保
panic确实是来自你想要测试的逻辑点。当然，如果函数B的
panic就是函数A设计的一部分，那另当别论。
最后，利用表驱动测试。就像上面的示例代码那样，将不同的输入、预期
panic状态和预期
panic消息组织成一个测试用例的切片。这不仅让测试代码更简洁，也更容易添加新的测试场景，确保你覆盖了所有预期的
panic条件和非
panic条件。这是一种非常Go-idiomatic的测试方法，能有效提升测试的覆盖率和可维护性。
recover
和error
处理机制的区别与选择
这是一个我经常思考的问题：什么时候该
panic，什么时候该返回
error？这不仅仅是语法上的选择，更是程序设计哲学上的差异，尤其是在测试时，我们需要明确我们到底在测试什么。
error
是Go语言中处理预期错误的首选机制。当一个函数在正常执行路径上可能会遇到问题，并且这些问题是调用者可以合理地预期和处理的，那么就应该返回一个
error。比如，文件不存在、网络连接超时、无效的用户输入等。调用者通过检查返回的
error值来决定如何继续执行，例如重试、向用户显示错误信息或回滚操作。
error的特点是它允许程序继续执行，并且提供了清晰的错误信息传递路径。我们测试
error，就是测试函数在特定输入下是否返回了预期的错误类型或错误消息。
panic
则用于处理非预期的、通常是不可恢复的运行时错误。这些错误通常表示程序进入了一个不应该出现的状态，继续执行下去可能会导致更严重的问题或数据损坏。典型的例子包括：空指针解引用（这是运行时自动
panic的）、数组越界、或者在程序启动阶段关键组件初始化失败。在库的设计中，有时也会主动
panic，表示调用者违反了API的契约（例如，传入了
nil参数给一个不允许
nil的函数，而这个
nil会导致内部逻辑彻底崩溃，且无法优雅地处理）。
panic的特点是它会中断当前Goroutine的正常执行流，并向上冒泡，直到被
recover捕获或者导致程序崩溃。
在测试中，我们使用recover
来验证那些我们设计上就预期会panic
的场景。这通常发生在两种情况：
-
验证库或框架的契约违背行为：如果你正在开发一个库，并且某些输入被认为是“不可能”或“严重错误”的，你可能会选择
panic
来强制调用者遵循API约定。测试时，你就会特意构造这些“违规”输入，然后用recover
来确认panic
确实发生了，且panic
信息符合预期。 -
验证初始化或关键路径的失败：在某些情况下，如果一个程序或模块在启动时无法获得必要的资源或配置，它可能选择
panic
而不是返回error
，因为它无法在没有这些条件的情况下继续运行。测试时，你会模拟这些失败条件，并验证panic
的发生。
所以，选择
panic还是
error，归根结底是关于“错误性质”的判断：是可预期的、可恢复的，还是不可预期的、需要中断的。在测试时，我们就是去验证这种设计选择是否被正确地实现了。我们不会为每一个可能的错误都去测试
panic，而是只针对那些代码设计上明确会
panic的场景，利用
recover来确保这种“崩溃”行为是符合预期的。
