Go 接口应使用 testify/mock 自动生成 mock 以覆盖所有分支，尤其需显式模拟 error、空/nil 切片、HTTP 非 200 状态及 context 取消/超时路径，并通过 cover 工具定位未执行行。
用 testify/mock 覆盖接口依赖路径
Go 的接口抽象天然适合 mock，但直接手写 mock 类型容易漏实现方法、难维护。用 testify/mock 自动生成能显著提升覆盖率——尤其对 HTTP 客户端、数据库操作等外部依赖。
关键不是“要不要 mock”，而是“mock 是否覆盖了所有分支”。比如一个 UserService.GetUser 方法内部调用了 db.Find 和 cache.Get，若只 mock 成功路径，cache.Miss → db.Error 这条错误链就永远测不到。
- 为每个接口定义独立的 mock 文件（如
mocks/cache.go），避免复用导致状态污染 - 在测试中显式调用
mock.AssertExpectations(t)，防止忘记设置期望却误判通过 - 对返回 error 的分支，必须用
mock.On("Get", ...).Return(nil, errors.New("timeout"))显式触发
go test -coverprofile=cover.out && go tool cover -func=cover.out 查准未覆盖行
覆盖率数字本身没意义，真正有用的是定位哪一行没执行。很多人跑完 go test -cover 看到 85% 就停了，但可能核心的 if err != nil { log.Fatal() } 永远没进过 log.Fatal 分支。
go tool cover -func 输出按函数粒度列出覆盖率，比 -covermode=count 更快定位薄弱点；配合 -html=cover.html 可直观看到具体哪行红了。
立即学习“go语言免费学习笔记（深入）”；
- 优先补全 error 分支：Go 中
if err != nil后的处理逻辑常被忽略，但恰恰是 panic 或日志上报的关键路径 - 注意空切片和 nil 切片的区别：
len(s) == 0和s == nil是两个不同分支，都要构造对应测试数据 - HTTP handler 测试里，别只测
200，用httptest.NewRequest("POST", "/user", nil)强制触发400分支
用 gomock 测试带 context 的超时与取消逻辑
带 context.Context 参数的函数（如 Do(ctx context.Context, req *Req) (*Resp, error)）很难靠常规测试覆盖取消路径。手动 sleep 等 timeout 不稳定，还拖慢整个测试套件。
正确做法是传入一个已 cancel 的 context，或用 context.WithTimeout 配合短时间（如 1ms）来强制走 cancel 分支。
- 测试取消：用
ctx, cancel := context.WithCancel(context.Background()); cancel()，然后传ctx进函数 - 测试超时：用
ctx, _ := context.WithTimeout(context.Background(), 1*time.Millisecond)，确保函数内select { case 被击中 - 避免在测试里用
time.Sleep等待 goroutine，改用sync.WaitGroup或 channel 等待信号
测试并发安全代码时，用 go test -race 发现隐藏未覆盖竞争点
覆盖率工具只统计代码是否执行，不保证并发下逻辑正确。一个 sync.Map 的 LoadOrStore 调用可能 100% 覆盖，但若测试没压测并发读写，就发现不了 key 冲突时的 panic。
-race 不是覆盖率工具，但它能暴露“理论上该走但实际没走到”的竞争路径——比如两个 goroutine 同时调用 Inc，预期结果是 +2，但因缺少锁变成 +1，这种逻辑缺陷单靠行覆盖根本看不到。
- 给并发测试加
for i := 0; i 循环，提高 race detector 捕获概率 - 不要只在本地跑 race 测试，CI 中固定开启
go test -race ./...，因为 race 行为高度依赖调度 - 注意
testing.T.Parallel()本身不触发 race，它只是让测试并行运行；真正要测并发逻辑，得在测试函数里自己启 goroutine
覆盖率高不等于没 bug，但低覆盖率一定意味着某些分支完全没验证过。最常被忽略的是 error 处理里的日志格式化、context 取消后的资源清理、以及并发下的边界条件——这些地方不写测试，上线后出问题几乎无法复现。
