17370845950

t.Error和t.Errorf仅记录错误并继续执行，不终止测试；t.Fatal/t.Fatalf则立即终止当前测试函数。两者适用于不同断言需求：前者用于非关键错误提示，后者用于必须中断的失败场景。

testing.T.Error 与 Errorf 的区别和适用场景

直接调用 t.Error 或 t.Errorf 是最基础的错误报告方式，但它们不中断测试执行——即使出错，后续语句仍会运行。这在需要「失败即停止」的断言场景中容易掩盖问题。

• t.Error("failed")：纯字符串输出，适合简单提示
• t.Errorf("expected %v, got %v", want, got)：支持格式化，推荐用于值比对类错误
• 两者都只是记录错误并继续执行，**不是断言失败后立即终止测试**

如何让测试在错误时立即停止（类似 assert）

Go 标准库没有内置 assert，但可以用 t.Fatal / t.Fatalf 实现「失败即退出」效果。这是写可读、可维护测试的关键习惯。

if err != nil {
    t.Fatalf("unexpected error: %v", err)
}
// 后续代码只有 err == nil 时才会执行

• t.Fatal 和 t.Fatalf 会立刻结束当前测试函数，不执行后续语句
• 不要在循环内无条件用 t.Fatal，否则第一次失败就跳过其余迭代；需结合 break 或提前 return 处理
• 注意：子测试（t.Run）中使用 t.Fatal 只终止当前子测试，不影响父测试或其他子测试

检查错误是否为预期类型或值

仅判断 err != nil 不够严谨。常见需求是确认错误是否来自特定函数、是否含特定文本、或是否为某个自定义错误类型。

if !errors.Is(err, os.ErrNotExist) {
    t.Fatalf("expected os.ErrNotExist, got %v", err)
}
if !strings.Contains(err.Error(), "permission denied") {
    t.Fatalf("error message doesn't contain 'permission denied': %v", err)
}

• errors.Is(err, target)：安全判断错误链中是否包含目标错误（推荐用于标准错误变量）
• errors.As(err, &target)：尝试将错误转为具体类型，用于自定义错误结构体断言
• 避免直接用 err == someErr，因为错误可能被包装（如 fmt.Errorf("wrap: %w", err)）

在子测试中组织错误断言更清晰

多个错误场景混在一个测试函数里容易混乱。用 t.Run 拆分，每个子测试聚焦一种错误路径，失败时输出更明确。

func TestOpenFile(t *testing.T) {
    tests := []struct {
        name    string
        path    string
        wantErr bool
    }{
        {"missing file", "/no/such/file", true},
        {"empty path", "", true},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            _, err := os.Open(tt.path)
            if (err != nil) != tt.wantErr {
                t.Fatalf("os.Open(%q) error = %v, wantErr %v", tt.path, err, tt.wantErr)
            }
        })
    }
}

• 子测试名（t.Run 第一个参数）会出现在 go test -v 输出中，便于定位哪个 case 崩了
• 每个子测试有独立生命周期，t.Fatal 不影响其他 case
• 注意闭包变量捕获问题：循环中用 tt 要确保传值或显式复制，否则所有子测试可能共享最后一个值

错误断言真正的复杂点不在语法，而在理解「错误是否可比较」「是否被包装」「是否应被忽略」。别只盯着 err != nil，多花两秒想清楚这个错误到底该被怎么识别、怎么传递、怎么暴露给调用方。