go test -cover 的 95% 覆盖率不等于测试质量，因其仅统计代码行是否执行，不验证分支行为是否被正确测试；需重点覆盖 Gin handler 的绑定失败、中间件终止、业务 error 三类分支，并通过 httptest 模拟真实 HTTP 请求进行断言。
Gin 项目跑出的覆盖率数字，不等于测试质量——尤其当 go test -cover 显示 95% 时，可能连核心错误分支都没覆盖。
为什么 go test -cover 的结果容易误导人
Go 标准工具链的覆盖率统计只看「是否执行过某行」，不关心是否验证了行为。比如一个 Gin handler 里有 panic 分支、参数校验失败分支、数据库 error 分支，只要测试用例调用了该函数（哪怕只传了个空 struct），go test -cover 就会把整块逻辑标为「已覆盖」。
- 常见错误现象：
go test -cover报 100%，但实际漏测c.AbortWithStatusJSON(400, ...)分支，上线后 400 错误返回格式错乱 - 使用场景：适合快速评估代码「有没有被碰过」，不适合判断「有没有被测对」
- 参数差异：
-covermode=count比atomic更能看出哪些分支真正被执行多次，但 CI 中常用atomic避免竞态 - 性能影响：启用
-covermode=atomic会轻微拖慢测试速度（尤其并发多时），但比count更稳定
Gin handler 测试必须覆盖的 3 类真实分支
光调用 r.GET(...) 并发请求远远不够。Gin handler 的逻辑往往藏在中间件、绑定、校验、业务逻辑、错误处理这五层里，其中三类分支最容易被忽略：
-
c.ShouldBindJSON()失败路径：测试时故意传 malformed JSON，确认是否走到c.Error(...)或c.Abort() - 中间件提前终止路径：比如 auth 中间件返回 401，handler 函数体本身根本没执行——此时 handler 内部代码行覆盖率仍是 0%
- 业务 error 分支：比如
user, err := db.FindByID(id)后的if err != nil分支，必须用 mock 数据库让 err 非 nil，再断言响应状态码和 body
如何用 httptest + testify/assert 写出有效覆盖率
直接构造 *gin.Context 是反模式——它绕过 Gin 的整个请求生命周期，导致中间件、绑定、日志等关键路径完全不执行。正确做法是走 HTTP 层模拟真实请求。
- 示例片段：
req, _ := http.NewRequest("GET", "/users/123", nil) req.Header.Set("Authorization", "Bearer invalid-token") w := httptest.NewRecorder() r.ServeHTTP(w, req) assert.Equal(t, 401, w.Code) - 不要用
gin.CreateTestContext模拟 context，它无法触发中间件链和绑定逻辑 - 对需要 DB 的 handler，用
sqlmock或gomock控制返回 error，而不是跳过 DB 层直接测 handler 函数 - 每个测试用例应明确断言：状态码、body 字段、header、是否写入日志（可通过重定向
gin.DefaultWriter捕获）
coverage.sh 脚本里的 mode: atomic 不是银弹
很多项目抄了 Golang-Gin-RealWorld 的 coverage.sh，但没注意它默认只统计 ./... 下的包，而忽略 internal/ 或 cmd/ 目录。更麻烦的是，它把所有 .go 文件一股脑塞进 go test，结果第三方依赖里的测试也被计入总行数，拉低真实覆盖率。
- 检查你的
coverage.txt是否混入了 vendor 或 testdata 目录下的文件路径 - 推荐改用
go test ./... -coverprofile=coverage.out -covermode=atomic -coverpkg=./...，显式指定被测包 - CI 中建议加一行校验：
awk '/^mode:/ {next} {sum += $3; count++} END {print sum/count}' coverage.out | awk '{if ($1 ，避免数值虚高 - 真正难测的是 Gin 中间件和全局配置初始化逻辑——它们往往在
main()或 init 函数里，需要单独启动 server 并发请求才能触达
覆盖率工具不会告诉你哪条 if 分支没测，只会告诉你哪行没执行。真正的覆盖，靠的是对 handler 执行路径的逐层拆解，而不是追着数字跑。
