表驱动测试适合错误处理场景，因它能高效覆盖多种错误情况。使用表驱动方式可集中管理错误输入与预期输出，结构清晰且易扩展；构造测试用例时需明确测试名称、输入参数及期望错误信息；测试中应检查错误是否非 nil、错误信息是否匹配，并确保数据为 nil；注意避免直接比较 error 对象，区分系统与业务错误，可封装通用断言函数；该方式适用于多错误分支、特定输入组合、不同错误码或消息、多次调用不同参数等场景。
测试 Golang 的错误处理逻辑是编写健壮代码的重要一环，尤其是在构建库或服务时。错误处理如果不经过充分验证，很容易在运行时导致不可预料的问题。而表驱动（table-driven）的测试方式，能让我们更清晰、高效地覆盖多种错误场景。
为什么用表驱动方式写错误测试？
在 Go 中，函数返回错误是很常见的做法。很多时候一个函数可能会因为多种原因出错，比如参数校验失败、外部调用失败、资源不存在等。如果我们为每种情况单独写测试函数，会显得重复又难以维护。
使用表驱动的方式，可以把各种错误输入和预期输出集中在一个切片里，通过遍历执行，统一验证逻辑。这样不仅结构清晰，也便于后续扩展和修改。
立即学习“go语言免费学习笔记（深入）”；
如何构造错误测试用例？
构造测试用例的关键在于模拟不同的输入条件，并明确期望的错误信息或类型。
以一个简单的文件读取函数为例：
func ReadFile(name string) ([]byte, error) {
if name == "" {
return nil, errors.New("filename is empty")
}
// 实际读取逻辑...
}我们可以构造如下测试用例：
tests := []struct {
name string
filename string
wantErr string
}{
{"empty filename", "", "filename is empty"},
{"non-existent file", "not-exist.txt", "open not-exist.txt: no such file or directory"},
}每个测试项都包含：
- 测试名称（用于调试）
- 输入参数
- 预期错误信息
然后通过循环执行并断言：
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
data, err := ReadFile(tt.filename)
if err == nil {
t.Errorf("expected error, got nil")
return
}
if !strings.Contains(err.Error(), tt.wantErr) {
t.Errorf("got %q, want %q", err.Error(), tt.wantErr)
}
if data != nil {
t.Errorf("expected nil data on error, got %v", data)
}
})
}常见注意事项与技巧
- 不要忽略 nil 检查：有些函数在出错时可能返回非 nil 的 error 接口但内容为空，这种情况要特别注意。
- 避免直接比较 error 对象：除非你确定用的是同一个 error 变量，否则建议比较字符串或使用自定义错误类型判断。
- 区分系统错误和业务错误：比如 os.Open 返回的 error 是具体的系统错误，不能硬编码比对，只能检查是否包含某类错误。
- 可以封装通用断言函数：如果多个测试都需要类似的错误检查逻辑，可以提取成辅助函数。
举个例子：
func assertError(t *testing.T, err error, wantErrMsg string) {
if err == nil {
t.Fatal("expected error but got nil")
}
if !strings.Contains(err.Error(), wantErrMsg) {
t.Errorf("error message mismatch: got %q, want %q", err.Error(), wantErrMsg)
}
}表驱动测试适合哪些场景？
- 函数有多个错误分支
- 错误发生前需要特定输入组合
- 需要测试不同错误码或消息
- 同一个函数被多次调用，每次传参不同
这种模式广泛应用于参数校验、API 请求处理、数据库操作等场景中。
基本上就这些。写好错误测试不是最难的事，但确实容易被忽视。用表驱动的方式组织测试，能让你的代码更可靠，也能让你更有信心面对各种边界情况。
