errors.Is和errors.As用于精准断言包装错误：errors.Is(err, ErrNotFound)判断是否为某哨兵错误（含任意包装层），errors.As(err, &target)提取并断言是否实现某接口。
如何用 errors.Is 和 errors.As 断言特定错误
Go 1.13 引入的 errors.Is 和 errors.As 是测试自定义错误类型的核心工具。直接比较 == 会失败，因为包装后的错误（如 fmt.Errorf("wrap: %w", err)）地址不同。
常见错误现象：断言 err == myErr 总是 false，即使错误语义相同；或用 strings.Contains(err.Error(), "xxx") 做模糊匹配，导致测试脆弱、易误报。
-
errors.Is(err, ErrNotFound)用于判断是否为某个哨兵错误（或其任意包装层） -
errors.As(err, &target)用于提取并断言错误是否实现了某接口（如*os.PathError） - 测试前确保被测函数返回的是你定义的哨兵错误或实现了目标接口的错误类型
func TestFetchUser_ErrorNotFound(t *testing.T) {
err := FetchUser(999)
if !errors.Is(err, ErrNotFound) {
t.Fatalf("expected ErrNotFound, got %v", err)
}
}
func TestOpenFile_ErrorPath(t *testing.T) {
err := os.Open("/nonexistent/file.txt")
var pathErr *os.PathError
if !errors.As(err, &pathErr) {
t.Fatal("expected *os.PathError")
}
if pathErr.Op != "open" {
t.Errorf("expected op 'open', got %q", pathErr.Op)
}
}
如何模拟并验证错误路径是否被正确执行
单元测试中要覆盖错误分支，关键不是“让函数出错”，而是“让依赖返回错误”，然后验证主逻辑是否按预期处理（比如是否提前返回、是否记录日志、是否重试等）。
使用场景：HTTP 客户端、数据库查询、文件操作等外部依赖出错时的控制流。
- 不要在测试里真实调用
os.Open或http.Get，而是通过接口抽象 + 依赖注入 - 给被测函数传入一个返回预设错误的 mock 实现（例如
func() ([]byte, error) { return nil, io.EOF }） - 检查返回值是否为预期错误，同时检查副作用（如是否调用了日志函数、是否设置了状态字段）
type FileReader interface {
ReadFile(name string) ([]byte, error)
}
func ProcessConfig(r FileReader, name string) error {
data, err := r.ReadFile(name)
if err != nil {
log.Printf("failed to read %s: %v", name, err)
return fmt.Errorf("config load failed: %w", err)
}
// ... process
return nil
}
func TestProcessConfig_ReadError(t *testing.T) {
mockReader := &mockFileReader{err: os.ErrNotExist}
err := ProcessConfig(mockReader, "config.json")
if !errors.Is(err, os.ErrNotExist) && !strings.Contains(err.Error(), "config load failed") {
t.Fatal("expected wrapped error with 'config load failed'")
}
// 还可检查 mockReader.logCalls 是否被触发（若需验证日志）
}
为什么 t.Error 比 panic 更适合错误路径测试
新手常在错误分支里写 if err != nil { panic(err) } 来“快速失败”，但这会让测试中途崩溃，无法继续执行后续断言，也掩盖了错误处理逻辑本身是否正确。
性能与可维护性影响：panic 触发堆栈捕获，开销大；且一旦 panic，该测试函数立即终止，无法得知其他分支是否也出问题。
- 用
t.Errorf或t.Fatalf显式报告失败，保持测试可控 -
t.Fatalf适用于“前置条件不满足”（如 setup 失败），而非业务错误 - 业务错误必须作为返回值参与断言，这是 Go 错误处理契约的一部分
容易忽略的边界：nil 错误 vs 空错误字符串 vs 自定义零值错误
测试时最容易漏掉的是对 nil 错误的显式校验，尤其当函数文档没说清“成功时是否保证返回 nil”时。
常见陷阱：把 err != nil 当作“有错误”，但某些库（如 json.Unmarshal）在输入为空字节时返回 nil，而另一些函数可能返回 &MyErr{Msg: ""} —— 它非 nil，但 err.Error() 是空字符串。
- 永远优先用
if err != nil判断，而不是if err.Error() != "" - 若自定义错误类型有零值（如
type MyErr struct{ Code int }），确保其实现了Error() string并在Code == 0时返回有意义内容，或明确禁止零值构造 - 在测试中补全
nil分支：既测“有错”，也测“没错”，尤其涉及缓存、短路逻辑时
复杂点在于：错误是否被多次包装、是否跨 goroutine 传播、是否在 defer 中被覆盖——这些都会让 errors.Is 失效或行为难预测。动手前先确认错误链是否干净。
