Go など package 単位で coverage を測るプロジェクトでは、go test ./... -coverprofile をそのまま使うと、生成 mock、test helper、interface だけの package、DTO/response 変換だけの薄い package、bootstrap や migration 補助などが分母に入り、総 coverage が実際の品質判断とずれやすい。

判断基準:

• coverage を「テスト拡充の判断材料」にしたいなら、分母は handler、usecase、domain model、middleware、外部 adapter など、挙動リスクを判断したい本番コードに寄せる。
• 生成コード、テスト補助、mock、interface-only package、単純 DTO は除外候補にする。これらは coverage が 0% でも挙動リスクを直接示しにくく、逆に本当に薄い実行経路を埋もれさせる。
• DB repository など Docker や実 DB に依存する層は、unit coverage と integration coverage を分ける。通常 coverage に混ぜると実行コストや環境依存が増え、日常的な指標として使いづらくなる。
• 除外対象はコマンドに埋め込むだけでなく、対象 package を表示する確認ターゲットを用意すると、分母の妥当性をレビューしやすい。

落とし穴: Makefile の $(shell go list ...) は、環境によって go list が失敗しても空文字として展開され、意図しない対象で coverage が進むことがある。coverage 用 package の解決は recipe 内で行い、解決結果が空なら明示的に失敗させるとよい。

検証方法: 対象 package 一覧を出力し、生成物・test helper・mock が含まれていないことを確認する。そのうえで coverage 総値を見る。総値が大きく変わった場合は「テストが増えた」のではなく「分母が変わった」ため、変更前後の対象範囲を併記して扱う。