如何在Golang中测试错误分支逻辑_Golang错误单元测试方法_技术教程

错误分支测试需用 errors.New/fmt.Errorf 创建具名错误变量，通过 errors.Is/errors.As 精确断言；mock 依赖时主动注入预设错误；注意 defer 中 Close 等可能出错的调用；避免字符串匹配错误。

用 `errors.New` 或 `fmt.Errorf` 构造可预测的错误值

测试错误分支的前提是让被测函数返回的错误能被稳定识别。直接比较 err == nil 不够，要验证错误类型、消息甚至底层结构。优先用 errors.New 创建具名错误变量，避免每次调用都生成新实例：

var (
    ErrNotFound = errors.New("user not found")
    ErrInvalidID = fmt.Errorf("invalid user id: %w", errors.New("id must be positive"))
)

这样在测试中可用 errors.Is(err, ErrNotFound) 或 errors.As(err, &target) 精确断言，而不是依赖易变的错误字符串。

在 mock 依赖时主动注入错误路径

真实错误往往来自外部调用（如数据库、HTTP 客户端）。测试时不要

等它“自然发生”，而是通过接口抽象 + 依赖注入，让 mock 实现直接返回预设错误：

type UserRepository interface {
    GetByID(ctx context.Context, id int) (*User, error)
}

// 测试用 mock
type mockUserRepo struct {
    returnErr error
}

func (m *mockUserRepo) GetByID(ctx context.Context, id int) (*User, error) {
    return nil, m.returnErr
}

// 在测试中：
repo := &mockUserRepo{returnErr: ErrNotFound}
user, err := svc.GetUser(ctx, 123, repo)
if !errors.Is(err, ErrNotFound) {
    t.Fatal("expected ErrNotFound")
}

避免在 mock 里写条件逻辑（比如 “当 id==0 时返回错误”），那会让测试行为隐晦且难覆盖边界
如果原接口返回的是 *sql.ErrNoRows 这类具体类型，mock 也应返回同类型指针，否则 errors.As 会失败

注意 `defer` 中的错误被忽略的常见陷阱

很多 Go 函数在 defer 里关闭资源（如 file.Close()），而这些调用也可能返回错误。若主逻辑已出错，defer 错误常被丢弃，导致测试漏掉资源泄漏或清理失败场景：

func processFile(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close() // Close() 可能返回 error，但这里被忽略

    // ... 处理逻辑
    return nil
}

测试这类函数时，不能只检查主错误，还要确保 Close 被调用且其错误被正确处理。可行做法：