Go测试返回值需用got/want变量显式比较并调用t.Errorf；多返回值须验证error，成功路径用t.Fatalf，失败路径用errors.Is检查；表驱动测试应使用t.Run和结构体字段name/input/want/wantErr；testify/assert适用于深比较但会终止子测试。
测试函数返回值的基本写法（Go test）
Go 原生 testing 包不提供断言函数，验证返回值靠的是显式比较 + t.Errorf。别指望 assert.Equal 那套——那是第三方库的玩法，标准做法是直接写判断逻辑。
例如测试一个加法函数：
func Add(a, b int) int {
return a + b
}
func TestAdd(t *testing.T) {
got := Add(2, 3)
want := 5
if got != want {
t.Errorf("Add(2,3) = %d, want %d", got, want)
}
}
- 必须用
got和want变量命名，这是 Go 社区约定，便于快速识别实际值与期望值 - 错误信息里要同时输出
got和want，否则失败时只能看到一行 “want 5”，根本不知道实际返回了啥 - 别在
if分支里只写t.Fatal——它会立刻终止当前测试，掩盖后续 case 的问题；优先用t.Errorf让所有 case 都跑完
处理多返回值和 error 的常见坑
Go 函数常返回 (result, error)，测试时容易漏掉对 error 的检查，或把 nil 当成 “没出错” 就完事。实际上，error 是一等公民，必须显式验证。
比如测试一个可能失败的除法函数：
立即学习“go语言免费学习笔记（深入）”；
SerpApi Flights (Google Flights)
下载
通过 SerpApi 查询 Google Flights，获取航班时刻表、价格及舱位等级信息。当用户询问航班 / 机票 / 航班价格、时刻表或对比信息时使用。
func Divide(a, b float64) (float64, error) {
if b == 0 {
return 0, errors.New("division by zero")
}
return a / b, nil
}
func TestDivide(t *testing.T) {
// 测试成功路径
got, err := Divide(10, 2)
if err != nil {
t.Fatalf("unexpected error: %v", err) // 这里用 Fatal 合理：成功路径不该有 error
}
if got != 5.0 {
t.Errorf("Divide(10,2) = %f, want 5.0", got)
}
// 测试失败路径
_, err = Divide(10, 0)
if err == nil {
t.Error("expected error for division by zero, got nil")
}
if !strings.Contains(err.Error(), "division by zero") {
t.Errorf("error message doesn't match: %v", err)
}
}
- 成功路径中，先检查
err != nil，再用t.Fatalf中断——因为此时出错属于严重逻辑缺陷 - 失败路径中，不能只检查
err != nil，还要验证错误内容是否符合预期，尤其当函数返回自定义 error 类型时，应优先用errors.Is或errors.As判断 - 别用
reflect.DeepEqual比较 error：它只比内存结构，不比语义；errors.Is才是正确姿势
表驱动测试（table-driven tests）怎么组织返回值验证
当一个函数需要测多个输入组合时，硬写一堆 TestXxx 函数既冗余又难维护。Go 推荐用切片+循环的表驱动方式，每个测试项明确标注 name、input、want、wantErr。
关键点在于：每个子测试要用 t.Run 单独包裹，否则失败时无法定位具体是哪个 case 出问题：
func TestParseInt(t *testing.T) {
tests := []struct {
name string
input string
want int
wantErr bool
}{
{"positive", "42", 42, false},
{"negative", "-7", -7, false},
{"invalid", "abc", 0, true},
{"empty", "", 0, true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := strconv.Atoi(tt.input)
if (err != nil) != tt.wantErr {
t.Errorf("error mismatch: got error %v, wantErr %t", err, tt.wantErr)
return
}
if !tt.wantErr && got != tt.want {
t.Errorf("got %d, want %d", got, tt.want)
}
})
}
}
- 结构体字段名统一用
name/input/want/wantErr，团队协作时一眼能懂 -
t.Run的第一个参数必须是tt.name，否则go test -run=TestParseInt/positive这类子测试过滤就失效 - 注意括号：判断 error 是否发生要用
(err != nil) != tt.wantErr，而不是err != nil != tt.wantErr（后者语法错误）
什么时候该用 testify/assert 而不是原生 testing
原生写法清晰可控，但写多了容易重复：每行都得写 if got != want { t.Errorf(...) }。当你频繁测试 JSON 序列化、嵌套结构体、slice 元素顺序，或者需要深比较时，testify/assert 的可读性优势就出来了。
但它不是银弹——引入后要注意三点：
- 所有
assert函数（如assert.Equal）内部调用的是t.FailNow，即失败立即终止当前子测试，无法像原生那样继续执行后续校验逻辑 - 如果项目要求零外部依赖，或者 CI 环境禁止非标准库，那就必须坚持原生写法
-
assert.JSONEq对空格和 key 顺序不敏感，适合比对 API 返回，但如果你需要精确匹配格式（比如生成配置文件），就得回退到bytes.Equal或cmp.Diff
复杂结构体的深比较，cmp.Diff（来自 github.com/google/go-cmp/cmp）比 testify/assert 更透明——它会输出详细差异，而不是一句 “not equal”。但代价是多一个 import，且需手动处理 unexported 字段。
