JaCoCo技術調査インフォグラフィック

1. コアメカニズム：オンザフライ・バイトコードインスツルメンテーション

JaCoCoはソースコードを直接扱わず、クラスロード時にJVMのメモリ上でJavaバイトコードを動的に書き換えます。この「オンザフライ」アプローチにより、ビルドプロセスを簡潔に保ちながら、正確な実行追跡を実現します。

①

開発者のコード
(.java)

→

↓

②

コンパイル
(.class)

→

↓

③

JaCoCoエージェント
が介入 🔧

クラスロード時にプローブを挿入

→

↓

④

テスト実行 &
データ収集

JaCoCoは複数のメトリクスを提供しますが、それぞれが示す意味は異なります。「行カバレッジ」は直感的ですが、「分岐カバレッジ」はコードの論理的な網羅性を測る上でより重要です。

一般的なプロジェクトにおける各メトリクスの達成状況の例です。

品質保証の観点から、どのメトリクスがより深い洞察を提供するかを示します。

重要ポイント：

行カバレッジが100%でも、条件分岐の一部がテストされていない可能性があります。レポートの黄色いひし形（◇）は、未実行の分岐を示しており、テストケースの追加が必要な箇所を教えてくれます。

JaCoCoはバイトコードを解析するため、コンパイラが生成する「合成コード」（例：Kotlinコルーチン）によってカバレッジが不当に低く報告されることがあります。これはJaCoCoのバグではなく、その動作原理に起因する特性です。

Kotlinのsuspend関数は、コンパイラによって複雑なステートマシンに変換されます。JaCoCoはこの自動生成された分岐も計測対象とするため、開発者が書いたコードが完全にテストされていても、分岐カバレッジが100%にならないことがあります。

この乖離は、Lombokや`try-with-resources`構文でも同様に発生する可能性があります。

⚡
PowerMock/Mockitoとの競合
両ツールがバイトコードを書き換えるため競合し、カバレッジが0%になる問題が発生します。解決策としてJaCoCoの「オフラインインスツルメンテーション」の利用が推奨されます。
🔍
リフレクションへの影響
JaCoCoは計測用の合成メンバー（$jacocoData）をクラスに挿入します。リフレクションで全メンバーを走査するコードは、isSynthetic()でこれらを除外する必要があります。

解決策

JaCoCoは継続的にフィルタを更新し、これらの問題を軽減しています。Lombokには`lombok.config`で`@Generated`注釈を付与させる設定が有効です。

通常、JaCoCoのオーバーヘッドは軽微ですが、多数のスレッドが同時に実行される高負荷な環境では、深刻なパフォーマンス低下を引き起こすことが報告されています。

原因は、複数のスレッドが単一の共有プローブ配列に書き込もうとすることで生じる「CPUキャッシュコンテンション」です。

カバレッジ率という数値を追うだけでは品質は向上しません。現代のCI/CDパイプラインでは、より実践的なアプローチが求められます。

「プロジェクト全体でカバレッジ80%を維持する」

「このPull Requestで変更されたコードのカバレッジを80%以上にする」