17370845950

应使用 errors.Is 或 errors.As 判断错误类型，避免直接比较 error 字符串；封装断言函数区分“必须无错”和“必须有特定错”；注意错误链完整性、堆栈可见性及 Error() 字符串的脆弱性。

测试 error 是否为预期类型（*errors.errorString 或自定义错误）

Go

中的 error 是接口，直接用 == 比较字符串容易失效（比如多次包装、格式化差异）。更可靠的方式是用 errors.Is 判断是否为某个底层错误，或用 errors.As 提取具体错误类型。

• 若函数返回 fmt.Errorf("failed: %w", io.EOF)，应使用 errors.Is(err, io.EOF) 断言，而非 err.Error() == "failed: EOF"
• 若定义了自定义错误类型如 type ValidationError struct{ Msg string }，需先用 errors.As(err, &target) 尝试转换，再检查字段
• 注意：只有用 %w 包装的错误才支持 errors.Is 向下穿透；%s 或 fmt.Sprintf 会切断错误链

在 test helper 函数中统一校验 error 返回

重复写 if err != nil { t.Fatal(err) } 容易漏掉非空但非预期的错误。推荐封装一个断言函数，明确区分「必须无错」和「必须有特定错」两种场景。

• 对「应成功」路径：写 mustNoError(t, err)，内部用 if err != nil { t.Fatalf("expected no error, got: %v", err) }
• 对「应失败」路径：写 mustErrorIs(t, err, io.EOF) 或 mustErrorAs(t, err, &validationErr)
• 避免在 helper 里用 t.Helper() 后再调 t.Fatal —— 这会导致报错行号指向 helper 内部，掩盖真实调用位置；改用 t.Fatalf 并手动加前缀更清晰

用 testify/assert 或 go-cmp 验证 error 的结构与消息

当需要比对错误消息内容（比如日志、用户提示），且确认该消息是稳定 API 的一部分时，可做字符串匹配，但要控制粒度。

• 用 assert.Contains(t, err.Error(), "invalid ID") 比全等更健壮，避免因空格、标点微调导致测试脆性
• 若错误实现了 Unwrap() error 或含字段（如 HTTPStatus int），用 cmp.Equal 深度比对结构体字段，而不是只看 Error() 输出
• 不建议在生产代码中依赖 err.Error() 做逻辑分支 —— 测试里也不该强化这种用法；优先走 errors.Is/As 路线

func TestFetchUser_ErrorCases(t *testing.T) {
    t.Run("not found returns ErrUserNotFound", func(t *testing.T) {
        client := &mockHTTPClient{status: 404}
        _, err := FetchUser(context.Background(), client, "123")

        var notFoundErr *UserNotFoundError
        if !errors.As(err, ¬FoundErr) {
            t.Fatalf("expected *UserNotFoundError, got %T: %v", err, err)
        }
        if notFoundErr.ID != "123" {
            t.Errorf("expected ID '123', got %q", notFoundErr.ID)
        }
    })
}

测试 error 的关键不在“有没有错”，而在于“错得是否精准”。最容易被忽略的是错误链断裂（没用 %w）、helper 函数吞掉真实堆栈、以及把 Error() 字符串当作契约来断言 —— 这三处一松动，错误处理测试就形同虚设。