17370845950

低覆盖率主因是未覆盖错误返回、边界输入、并发分支和私有逻辑；需构造失败场景、完善表驱动测试、显式验证并发与初始化副作用，并在CI中设置覆盖率门禁。

go test -cover 显示覆盖率低，不是数字问题，而是测试没打中关键路径。90% 的低覆盖率都集中在错误返回、边界输入、并发分支和私有逻辑上——这些地方不写针对性用例，光跑主流程永远卡在 60–70%。

为什么 if err != nil 总是红色？

因为你的测试没真正触发错误。比如调用 os.Open、json.Unmarshal 或自定义的校验函数时，只测了“成功”，没构造失败场景。

• 对文件操作：传入不存在路径或无权限路径，而非仅用 tempfile
• 对 JSON 解析：用非法字符串（如 "{key: value}" 缺少引号）、超长嵌套、空字节流
• 对业务校验函数：传 nil、空字符串、负数 ID、超长 slice —— 不要只测“看起来合理”的值

别依赖真实环境抛错；用接口抽象 + mock（如 io.Reader 替换为 bytes.NewReader(nil)）更稳定、更快。

表驱动测试没覆盖全分支？

table-driven tests 是 Go 最推荐的方式，但很多人只列了 2–3 个 case，漏掉关键组合。尤其当函数含多个 if 嵌套或 switch 分支时，单靠直觉容易遗漏。

• 把每个 if 条件单独拎出来设计输入：比如 if len(s) == 0、if s[0] == '{'、if !utf8.ValidString(s) 应各自有对应测试项
• 用 t.Run 命名明确表达意图，如 "empty_string_returns_error" 而非 "case1"
• 对返回 error 的函数，不仅要 assert.Error，还要 assert.Contains(err.Error(), "xxx")，确保走的是预期分支

func TestParseConfig(t *testing.T) {
	tests := []struct {
		name    string
		input   string
		wantErr bool
	}{
		{"empty", "", true},
		{"invalid_json", "{key: value}", true},
		{"valid", `{"timeout": 5}`, false},
		{"utf8_invalid", "\xff\xfe\xfd", true},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			_, err := ParseConfig(strings.NewReader(tt.input))
			if (err != nil) != tt.wantErr {
				t.Errorf("ParseConfig() error = %v, wantErr %v", err, tt.wantErr)
			}
		})
	}
}

并发代码和初始化逻辑为什么总不覆盖？

并发路径（如 go func() { ... }()）、init() 函数、包级变量赋值、http.HandlerFunc 中的中间件链，天然难触发。它们往往在覆盖率报告里整块变红，但没人专门去碰。

• 对 goroutine：用 sync.WaitGroup + time.After 或 channel 等待其完成，再断言结果
• 对 init()：无法直接调用，但可测试其副作用——比如是否注册了某 handler、是否设置了某全局 flag
• 对 HTTP handler：不要只测路由分发，要 mock http.ResponseWriter 和构造 *http.Request，覆盖 status code、header、body 写入逻辑

特别注意：go test -cover 默认不统计未执行的 goroutine 内部语句，必须确保测试能实际进入并退出该 goroutine。

CI 里加了 -cover 但还是倒退？

因为只生成报告，没设门禁。覆盖率下降没人知道，直到上线出问题。

• 在 CI 脚本里加检查：用 go tool cover -func=coverage.out | grep "total:" 提取数值，对比基线
• 拒绝低于阈值的提交（如 if $(awk '/total:/ {print $3}' coverage.txt | sed 's/%//') -lt 85; then exit 1; fi）
• 避免用 -covermode=count 做门禁——它统计执行次数，容易被循环刷高，失真；用默认的 atomic 或 set 模式更准

最常被忽略的一点：覆盖率工具不会告诉你「哪行该测但没测」，只会标红。真正要提升质量，得打开 coverage.html，点进每个红块，问

自己：“这段逻辑在什么情况下会执行？我有没有让它执行过？”——答案就是下一个测试用例。