Golang测试中Fatal与Error的区别说明

t.Fatal立即终止测试函数并标记失败，t.Error仅标记失败但继续执行；前者用于前置条件不满足等不可恢复错误，后者适用于需收集多个错误的场景。

t.Fatal 和 t.Error 的核心区别：是否中断执行

根本区别就一条：t.Fatal 一调用就立刻退出当前测试函数，t.Error 只标记失败但继续跑完剩余代码。这不是“语气轻重”问题，而是控制流是否被截断的实质性差异。

什么时候必须用 t.Fatal？前置条件不满足时

当后续断言或逻辑严重依赖某个前提（比如初始化失败、配置缺失、mock 未 setup），再往下跑毫无意义甚至会 panic，就必须用 t.Fatal 或 t.Fatalf。

• 常见错误现象：测试因 nil pointer panic 报错，但真实原因是前面 db.Connect() 失败后没终止，却继续调用了 db.Query()
• 正确做法：检查 setup 步骤，失败立即 t.Fatalf("failed to init db: %v", err)
• 不要用 t.Error 替代——它不会阻止后续代码执行，可能掩盖真正的问题源头

什么时候该用 t.Error？需要收集多个失败点

当你希望一次运行暴露出所有不一致项（比如批量校验字段、对比结构体多个字段），而不是只看到第一个就停住，就该用 t.Error 或 t.Errorf。

• 典型场景：表格驱动测试中，对一组输入逐一验证，想看到全部失败项而非只第一个
• 参数差异：t.Errorf("field X mismatch: got %v, want %v", got.X, want.X) 比 t.Fatal 更利于调试定位
• 注意：这些日志默认不输出，需加 -v 参数才能看到；而 t.Fatal 的消息总会显示

别踩的坑：混用日志与断言、忽略 Helper 语义

t.Log 和 t.Error 看似都是输出，但行为完全不同：前者只是记录，后者会翻红并影响测试结果；且它们都只在当前测试函数内有效，子测试里要显式传 t。

• 绝对避免：fmt.Println 或 log.Printf —— 它们逃逸出 testing 框架，无法被 go test -v 统一管理，还会污染标准输出
• 子测试中误用：在 t.Run("case1", func(t *testing.T) { ... }) 内部，必须用传入的 t，不能闭包引用外层 t
• 调试时建议加 t.Helper()：让错误行号指向真正调用处，而不是框架内部，尤其在封装断言函数时

func TestDivide(t *testing.T) {
    t.Helper()
    tests := []struct{
        a, b   int
        want   int
        wantErr bool
    }{
        {10, 2, 5, false},
        {10, 0, 0, true},
    }
    for _, tt := range tests {
        t.Run(fmt.Sprintf("divide(%d,%d)", tt.a, tt.b), func(t *testing.T) {
            t.Helper()
            got, err := divide(tt.a, tt.b)
            if tt.wantErr {
                if err == nil {
                    t.Fatal("expected error but got nil") // 前置条件失败，必须终止
                }
                r
eturn
            }
            if err != nil {
                t.Errorf("unexpected error: %v", err) // 允许继续检查 got 值
                return
            }
            if got != tt.want {
                t.Errorf("got %v, want %v", got, tt.want) // 收集多个错误
            }
        })
    }
}

关键不是记哪个“更严重”，而是看你要不要让测试继续往下走——这直接决定你能看到多少线索，也决定 CI 上失败报告是否可读。