Go测试应覆盖到哪些程度？Go测试策略推荐

Go测试应分层设定覆盖率目标：核心逻辑≥90%、错误处理100%、工具类≥80%；必用-covermode=atomic和-coverpkg=./...；表驱动测试+require更高效；合并覆盖率须用gocovmerge且确保-coverpkg一致。

核心结论：Go测试不追求100%语句覆盖率，而应分层设定目标——核心业务逻辑≥90%，错误处理必须100%，辅助工具类≥80%即可。

按模块类型定覆盖率目标，不是所有代码都值得同等覆盖

go-github项目实践表明，盲目堆高整体覆盖率反而稀释测试有效性。比如 RepositoriesService 这类直接映射GitHub API的主服务，必须覆盖所有参数组合、分页边界、404/422/500等HTTP错误分支；但 timestamp 包里一个简单的 ParseTime 函数，只要覆盖空字符串、非法格式、RFC3339标准时间三种输入就足够。

• API服务层（如 UsersService）：重点测请求构造、响应解码、重试逻辑，目标 ≥90%
• 错误处理路径（如 if err != nil 分支）：必须100%覆盖，且要注入真实错误（网络超时、JSON解析失败），不能只 mock err != nil
• 工具函数（如 strings 子包）：覆盖空输入、极端长度、UTF-8边界即可，≥80%合理

用 -covermode=atomic 而非 count 或 set，尤其在集成测试中

并发场景下，count 模式会因竞态导致行计数丢失，set 模式又无法区分“执行一次”和“执行百次”。atomic 是唯一能准确统计多 goroutine 下真实执行频次的模式。

• 单元测试可放宽，但集成测试必须加 -covermode=atomic
• 漏掉 -coverpkg=./... 会导致只统计测试文件本身，业务代码全标红——这是最常被忽略的配置项
• CI 中建议强制检查：go test -covermode=atomic -coverpkg=./... -coverprofile=unit.cov ./...

表驱动测试 + require 组合，比写一堆 TestXxx 更高效

Lo 库和 go.uuid 的实践都验证了：用切片定义输入/期望/错误类型，配合 require 在前置条件失败时立即终止，能快速暴露数据构造问题，避免后续断言报一堆无关错误。

func TestValidateUser(t *testing.T) {
    tests := []struct {
        name     string
        input    User
        wantErr  bool
        wantCode int
    }{
        {"empty name", User{}, true, http.StatusBadRequest},
        {"valid user", User{Name: "Alice"}, false, 0},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            require := require.New(t)
            err := ValidateUser(tt.input)
            if tt.wantErr {
                require.Error(err)
                require.Equal(tt.wantCode, GetHTTPStatus(err))
            } else {
                require.NoError(err)
            }
        })
    }
}

合并多阶段覆盖率时，别直接用 go tool cover 处理多个 .cov 文件

go tool cover 本身不支持合并，强行 cat 多个 .cov 会破坏格式，生成的 HTML 报告里大量行号错位。必须用 gocovmerge 这类专用工具。

• 集成测试生成 integration.cov，UI 测试生成 ui.cov，先统一放 ./coverage/ 目录下
• 运行：gocovmerge ./coverage/*.cov > final.cov（注意不是 go tool cover -func=...）
• 再执行：go tool cover -html=final.cov -o coverage.html

最容易被忽略的是：合并前没确认各 .cov 文件是否用相同 -coverpkg 参数生成——包路径不一致会导致合并后部分文件完全消失。