本文介绍在 go 单元测试中，如何简洁、可靠地断言函数返回值“是否存在”（即是否为非 nil），而不关心具体值内容，避免直接比较指针或结构体带来的复杂性和潜在 panic。
本文介绍在 go 单元测试中，如何简洁、可靠地断言函数返回值“是否存在”（即是否为非 nil），而不关心具体值内容，避免直接比较指针或结构体带来的复杂性和潜在 panic。
在 Go 测试中，当被测函数返回一个可能为 nil 或指向具体值的指针（如 *CustomType）时，常见误区是直接使用 actual == case.Expected 进行比较——这不仅逻辑错误（nil 与非 nil 指针永远不等，且不同地址的 *CustomType 即使内容相同也不相等），还可能因解引用 nil 指针引发 panic。
更安全、语义更清晰的做法是仅关注“存在性”：即判断 actual 与 case.Expected 在 nil 性上是否一致。核心逻辑是：
if (actual == nil) != (case.Expected == nil) {
t.Fatalf("expected %v-nil, got %v-nil for input %q",
nilOrNot(case.Expected), nilOrNot(actual), case.Input)
}其中 (actual == nil) != (case.Expected == nil) 表达的是：两者 nil 状态不一致时触发失败（!= 返回 true 表示 mismatch）。相比手动写四分支条件，该写法简短、无歧义、可读性强，且天然规避了指针比较和空值解引用风险。
完整测试示例：
func TestSomeFunc(t *testing.T) {
type testCase struct {
Input string
Expected *CustomType
Err error
}
tests := map[string]testCase{
"returns concrete value": {
Input: "valid",
Expected: &CustomType{},
Err: nil,
},
"returns nil": {
Input: "invalid",
Expected: nil,
Err: ErrSomeError,
},
}
for name, tc := range tests {
t.Run(name, func(t *testing.T) {
actual, err := SomeFunc(tc.Input)
// 断言 error 是否匹配
if !errors.Is(err, tc.Err) {
t.Fatalf("unexpected error: got %v, want %v", err, tc.Err)
}
// ✅ 核心：断言返回值存在性（nil 状态一致性）
if (actual == nil) != (tc.Expected == nil) {
t.Fatalf("nil mismatch: expected %t-nil, got %t-nil",
tc.Expected == nil, actual == nil)
}
})
}
}? 注意事项：
- 此方法适用于所有可为 nil 的类型（指针、slice、map、chan、func、interface{}）；
- 若需进一步验证非 nil 值的内部字段，应在 actual != nil 确认后单独断言；
- 避免在测试中对 case.Expected 做 *CustomType 解引用（如 *tc.Expected），以防 nil panic；
- 使用 t.Run 组织子测试，提升错误定位效率与可读性。
总结：用 (a == nil) != (b == nil) 替代冗长的条件组合，是 Go 测试中表达“存在性一致”的惯用、健壮且符合 Go 风格的写法——它聚焦契约（是否返回值），而非实现细节（返回什么值）。
