🤯AIで作ったコードのカバレッジ...低すぎ！？
Spec駆動開発で先にテストを書きながら進めていたのですが、ふとCIのカバレッジ率をみるとなんと57.3％
Googleのテストブログによると60％以上で許容範囲とあるのでそれに比べたら圧倒的に低いですね。
観点的には問題ないはずだし、境界値を使うロジックもないのでテストが本質的に難しい部分のテスト実行率が悪いのかなと仮説を立てて調査だけお願いしました。
🧪Claude Codeに原因分析してもらった
パッケージ別カバレッジまとめ
| パッケージ | カバレッジ | 状態 |
|---|---|---|
| middleware | 100.0% | ✅ 良好 |
| model | 100.0% | ✅ 良好 |
| router | 90.9% | ✅ 良好 |
| logger | 94.4% | ✅ 良好 |
| metrics | 90.0% | ✅ 良好 |
| handler | 85.7% | ✅ 良好 |
| config | 83.3% | ✅ 良好 |
| service | 77.8% | 🟡 改善可能 |
| httpserver | 64.3% | 🟡 改善可能 |
| database | 40.0% | ⚠️ 要改善 |
| repository | 7.7% | ❌ 最優先で改善必要 |
| cmd/auth-service | 0.0% | ⚠️ main関数 |
| cmd/migrate | 0.0% | ⚠️ main関数 |
みたところ、repository層のカバレッジ率が有意に低いようです。原因を分析してもらうと、Postgressに依存する部分のテストがSkipされていたようです。そこで、CIの時間がかかることを許容してテストを実行するようにコードを変更しました。Buildやスモークテストが長いので並走して長いCIが走る分には問題ないという判断です。
📘学び
- repository層のテストをSkipすると見た目上のカバレッジが低くなることもある
- repository層のユニットテストの設計はあらかじめ考える必要がある
- カバレッジを最初から出したために変更が最小限で抑えられた
📌課題
- repository層の単体テストの実現
- go-sqlmock なるライブラリがあるらしい
- E2Eテストの時間省力化