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解析失败），不能只 mockerr != 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 在前置条件失败时立即终止，能快速暴露数据构造问题，避免后续断言报一堆无关错误。
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
立即学习“go语言免费学习笔记（深入）”；
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 参数生成——包路径不一致会导致合并后部分文件完全消失。
