Go测试不内置断言函数，官方推荐用t.Errorf显式校验并输出got/want值；表格驱动测试需为每个case添加唯一错误前缀；第三方断言库虽简化代码但可能掩盖调用栈和执行流。
Go测试里没有内置断言函数
Go标准库的 testing 包不提供类似 assert.Equal() 或 assert.True() 这样的断言函数。这是有意设计：Go鼓励显式错误处理和清晰的失败信息，而不是靠断言库“吞掉”细节。直接写 if got != want { t.Errorf(...) } 是官方推荐方式，也是最可控的做法。
用 t.Errorf 写可读的校验逻辑
手写校验不等于重复造轮子，关键是把错误信息写清楚。常见陷阱是只写 t.Errorf("failed")，导致失败时看不出哪一步出错、输入输出是什么。
- 总是带上实际值（
got）和期望值（want），尤其对结构体、切片、map 要用fmt.Sprintf("%+v", x) - 对长字符串或大结构体，考虑用
diff工具辅助——但先确保你打印了足够上下文 - 避免嵌套过深的 if 判断；一个测试函数聚焦一个行为，一次只校验一个核心结果
func TestParseURL(t *testing.T) {
u, err := url.Parse("https://example.com/path?x=1")
if err != nil {
t.Fatalf("url.Parse failed: %v", err)
}
if u.Scheme != "https" {
t.Errorf("u.Scheme = %q, want %q", u.Scheme, "https")
}
if u.Host != "example.com" {
t.Errorf("u.Host = %q, want %q", u.Host, "example.com")
}
}
第三方断言库（如 testify/assert）能省什么、不能省什么
像 testify/assert 这类库确实能减少样板代码，但它掩盖了两个关键点：失败时的调用栈深度、以及是否真正中断执行。
-
assert.Equal(t, want, got)失败后不会自动停止当前测试函数，后续语句仍会执行 —— 除非你用require.Equal() - 错误信息虽自动拼接，但对自定义类型可能不友好（比如没实现
String()就打印空字符串） - 引入依赖会增加构建时间和 vendor 体积；CI 环境中若版本不一致还可能引发奇怪的格式化差异
import "github.com/stretchr/testify/assert"
func TestWithTestify(t *testing.T) {
result := Add(2, 3)
assert.Equal(t, 5, result, "2 + 3 should equal 5") // 日志带消息，但不会 panic
// 下面这行仍会执行，哪怕上一行失败了
assert.Greater(t, result, 0)
}
表格驱动测试 + 校验组合才是 Go 测试的主力模式
真实项目里，大量相似逻辑靠表格驱动（table-driven tests）覆盖，校验部分往往混在循环里。这时更要注意：每个 case 的错误信息必须唯一可识别。
- 用
tc.name作为错误前缀，例如t.Errorf("%s: got %v, want %v", tc.name, got, want) - 不要在循环里用
t.Fatal—— 它会让整个测试函数提前退出，跳过后续 case - 对返回 error 的函数，优先检查 error 是否为 nil，再检查业务字段；否则容易 panic
func TestSplit(t *testing.T) {
tests := []struct {
name string
input string
sep string
want []string
}{
{"empty", "", ",", []string{}},
{"single", "a", ",", []string{"a"}},
{"multi", "a,b,c", ",", []string{"a", "b", "c"}},
}
for _, tc := range tests {
t.Run(tc.name, func(t *testing.T) {
got := strings.Split(tc.input, tc.sep)
if !reflect.DeepEqual(got, tc.want) {
t.Errorf("%s: Split(%q, %q) = %v, want %v", tc.name, tc.input, tc.sep, got, tc.want)
}
})
}
}
校验逻辑越贴近业务含义，越不容易漏掉边界情况；而过度依赖断言库的“便利”，反而容易让错误信息变得模糊。真正难的不是怎么写断言，是怎么让失败时第一眼就看出问题在哪。 
