17370845950

Go 语言需用 testify/assert 实现断言，assert.Equal 默认不输出详细 diff，应对复杂类型用 EqualValues 或 ObjectsAreEqual；require 失败即终止测试，assert 则继续执行；HTTP 响应宜解码后结构化比对，自定义类型应实现 String() 提升错误可读性。

Go 语言原生没有 assert 机制，testify 的 assert 包是目前最主流的断言补充方案，但它不是“开箱即用”的魔法——用错方式会导致测试失败难定位、误报或漏报。

为什么 assert.Equal 失败时不打印详细 diff？

默认情况下 assert.Equal 只输出简略错误信息，比如 expected: 42, got: 43，对结构体或长字符串完全不友好。根本原因是没启用深度比较的可读格式化输出。

• 确保导入的是 github.com/stretchr/testify/assert（不是 require 或 mock）
• 对复杂类型（如 map、嵌套 struct），优先用 assert.EqualValues ——它会递归比较值而非指针/地址
• 若仍需完整 diff，改用 assert.ObjectsAreEqual + 自定义格式化，或直接切换到 require 包（见下节）

require 和 assert 的关键区别在哪？

require 不是更“强”的断言，而是失败时直接调用 t.Fatal 终止当前测试函数；assert 只记录错误，允许后续断言继续执行。选错会导致逻辑误判或掩盖真实问题。

• 验证前置条件（如 json.Unmarshal 成功）必须用 require.NoError：否则后续代码可能 panic 或读取 nil
• 批量校验多个字段（如 API 响应字段）适合用 assert：一次看到所有不匹配项
• require 的函数签名和 assert 完全一致，仅行为不同，可无痛切换

测试 HTTP handler 时如何用 assert 检查响应体？

直接对 *httptest.ResponseRecorder.Body 调用 assert.Equal 很容易因换行、空格、JSON 序列化顺序导致误判。核心是先标准化再比对。

func TestMyHandler(t *testing.T) {
	req := httptest.NewRequest("
GET", "/api/user", nil)
	rr := httptest.NewRecorder()
	handler := http.HandlerFunc(MyHandler)
	handler.ServeHTTP(rr, req)

	// 正确：解码 JSON 后比较结构体，绕过格式差异
	var resp map[string]interface{}
	assert.NoError(t, json.Unmarshal(rr.Body.Bytes(), &resp))
	assert.Equal(t, "success", resp["status"])
	assert.Equal(t, float64(200), resp["code"]) // 注意 JSON number 默认是 float64

	// 错误示例（避免）：
	// assert.Equal(t, `{"status":"success","code":200}`, rr.Body.String())
}

自定义类型断言失败时提示信息太模糊怎么办？

当结构体字段多、嵌套深时，assert.Equal 默认只显示 “expected …, got …”，看不出具体哪个字段不一致。根本解法是让类型实现 String() 方法，或用 assert.Exactly 强制类型+值双重匹配。

• 为测试专用结构体添加 String()：返回精简可读字段，便于快速定位
• 对时间、浮点数等易精度误差类型，用 assert.InDelta 或 assert.WithinDuration
• 避免在断言中拼接长字符串作 msg 参数——它只会追加在默认错误后，不替代原始 diff

真正麻烦的不是不会写 assert.Equal，而是没意识到它的输出本质是 fmt.Sprintf 格式化结果——一旦值本身不可读（比如未实现 Stringer 的 struct），断言失败就只剩内存地址和空括号。调试时花三分钟加个 fmt.Printf("%+v", v)，往往比翻文档快得多。