Close

コード カバレッジの概要

ここでは、コード カバレッジの利用を開始する、適切なツールを見つける、それを計算するそれぞれの方法について説明します。

Sten Pittet の顔写真
Sten Pittet

寄稿ライター


コード カバレッジはソースがどれくらいテストされているかを理解するのに役立つ指標で、テスト スイートの品質を評価するのに役立つ非常に便利な指標です。ここでは、プロジェクトの開始方法について説明します。

コード カバレッジはどのように計算されますか?


コード カバレッジ ツールは、1 つ以上の条件を使用してテスト スイートの実行中にコードがどのように実行されたかを判断します。カバレッジ レポートに記載される一般的な指標は、次のとおりです。

  • 関数カバレッジ: 呼び出しされた定義済み関数の数。
  • ステートメント カバレッジ: 実行されたプログラム内のステートメントの数。
  • ブランチ カバレッジ: 実行されたコントロール構造のブランチの数 (if ステートメントなど)。
  • 条件カバレッジ: true と false の値にテストされたブール値のサブ式の数。
  • 行カバレッジ: テストされたソース コード行の数。

通常、これらの指標は実際にテストされたアイテム数、コードで見つかったアイテム、カバレッジ率 (見つかったアイテムのうちテストされたアイテムの割合) を表します。

これらの指標は関連していますが、それぞれ異なります。以下の簡単なスクリプトには、引数が 10 の倍数であるかどうかをチェックする JavaScript 関数があります。後でその関数を使用して、100 が 10 の倍数であるかどうかを確認します。これは、関数カバレッジとブランチ カバレッジの違いを理解するのに役立ちます。

ソリューションを見る

Open DevOps によるソフトウェアの構築と運用

関連資料

DevOps の自動テスト

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else    return false; }   console.log(isMultipleOf10(100));


カバレッジ ツール istanbul を使用して、このスクリプトを実行したときにどれくらいコードが実行されるのかを確認できます。カバレッジ ツールを実行した後、カバレッジの指標を示すカバレッジ レポートが表示されます。関数カバレッジが 100% であるのに対して、ブランチ カバレッジはわずか 50% であることがわかります。また、istanbul コード カバレッジ ツールが条件カバレッジの指標を計算していないこともわかります。

コマンド ラインでカバレッジ レポートを取得する

スクリプトを実行したときに else ステートメントが実行されていないため発生します。100% のカバレッジを取得する場合は、別の行、基本的には別のテストを追加するだけで、if ステートメントのすべてのブランチが使用されていることを確認できます。

coverage-tutorial.js

function isMultipleOf10(x) {   if (x % 10 == 0)     return true;   else     return false; }   console.log(isMultipleOf10(100)); console.log(isMultipleOf10(34)); // This will make our code execute the "return false;" statement.  


カバレッジ ツールの 2 回目の実行で、下部にある 2 つの console.log() によってソースの 100% が羅列されていることがわかります。

すべての基準で 100% のカバレッジに到達する

この例ではターミナルに結果を記録しているだけですが、テスト スイートの実行時にも同じ原則が適用されます。コード カバレッジ ツールはテスト スイートの実行を監視して、テストの一部として実行されたステートメント、ブランチ、関数、行の数を通知します。

Javascript の istanbul は、各パスのカバレッジの詳細なレポートを表示できる

コード カバレッジの利用を開始する


プロジェクトに適したツールを見つける

使用する言語に応じて、カバレッジ レポートを作成するオプションがいくつか用意されています。人気のあるツールの一部を以下に示します。

istanbul のように結果をターミナルに直接出力するツールもあれば、コードのどの部分が羅列されていないかを調べられる完全な HTML レポートを生成できるツールもあります。

カバレッジ率の目標値

コード カバレッジに特効薬はありません。アプリケーションの重要な部分がテストされていない場合や、既存のテストが障害を事前に適切にキャプチャするのに十分な堅牢性がない場合は、高いパーセンテージのカバレッジが依然として問題になる可能性があります。そういう意味で、一般的に 80% のカバレッジがほど良い達成目標であると認められています。より高いカバレッジへの到達の試みは、コストがかかることが判明する可能性がありますが、十分なメリットを生み出す必要はありません。

カバレッジ ツールを初めて実行すると、カバレッジのパーセンテージがかなり低いことがわかるかもしれません。テストを始めたばかりの場合はこれは通常の状況であって、すぐに 80% のカバレッジに到達するというプレッシャーを感じるべきではありません。その理由は、カバレッジの目標に突入すると、アプリケーションのビジネス要件に基づくテストを作成するのではなく、コードのすべての行にヒットするテストを作成するようにチームを急き立てる可能性があるためです。

たとえば上記の例では、100 と 34 が 10 の倍数であるかどうかをテストして 100% のカバレッジに達しました。しかし、数字ではなく文字を使用して関数を呼び出した場合はどうなるでしょうか?true/false の結果を得る必要がありますか?それとも、例外を取得する必要がありますか?コード行を確認するだけでなく、ユーザーの観点からテストについて考える時間をチームに与えることが重要です。コード カバレッジでは、ソースに不足しているものがあるかどうかはわかりません。

まずユニット テストに注力する

ユニット テストの本質は、アプリケーションで使用されるクラスとコンポーネントの個々のメソッドが動作していることを確認することです。ユニット テストは一般的に、実装が安価で実行が速く、プラットフォームの基盤がしっかりしているという全体的な保証を提供します。コード カバレッジを迅速に増やす簡単な方法は、ユニット テストの追加から始めることです。これは当然、テスト スイートがコードのすべての行に到達していることを確認するのに役立ちます。

カバレッジ レポートを使用して、テストでの重大なミスを特定する

やがてコードに非常に多くのテストが含まれることになるため、テスト スイートの実行中にアプリケーションのどの部分がチェックされているかどうかを確認できなくなります。赤色ビルドが表示された場合は何が壊れているかがわかりますが、どのコンポーネントがテストに合格したかを把握するのは困難です。

ここで、カバレッジ レポートからチームの実践的なガイダンスが提供されます。ほとんどのツールでは、カバレッジ レポートを調べてテストで網羅されていない可能性がある実際のアイテムを確認し、アプリケーションで引き続きテストが必要な重要な箇所を特定できます。

Ruby の SimpleCov は、どの方法がテストされていないかを表示できる

準備ができたら、コード カバレッジを継続的インテグレーション フローの一部にする

継続的インテグレーション (CI) ワークフローを確立したら、カバレッジの十分なパーセンテージに達していない場合はテストの失敗を開始できます。もちろん前述のように、失敗のしきい値に高すぎる値を設定するのは不適切であり、90% のカバレッジによりビルドが何度も失敗する可能性があります。目標が 80% のカバレッジである場合は、CI 文化のセーフティ ネットとして失敗のしきい値を 70% に設定することを検討してください。

繰り返しになりますが、チームに良いカバレッジに到達するようにプレッシャーをかけると悪いテスト プラクティスにつながる可能性があるため、誤ったメッセージを送らないように注意してください。

良いカバレッジは良いテストではない

良いテスト文化を得るには、誰かがアプリケーションを適切に使用しているときだけでなくアプリケーションを壊そうとしたときも、アプリケーションがどのように動作するかをチームに理解させることから始めます。コード カバレッジ ツールは次に注意を向けるべき場所を理解するのに役立ちますが、予期しない動作に対して既存のテストが十分に堅牢であるかどうかを通知しません。

優れたカバレッジを達成することは素晴らしい目標ですが、個々のクラスが壊れていないことを確認するだけでなく、システムの整合性も検証できる堅牢なテスト スイートを用意することと組み合わせる必要があります。

ソフトウェア テストのさまざまな種類でご確認ください。

Sten Pittet
Sten Pittet

私はソフトウェアビジネスに 10 年間携わり、開発からプロダクトマネージメントまでさまざまな業務を経験してきました。アトラシアンで 5 年間開発ツールに携わった後、現在はソフトウェアの構築について記事を書いています。プライベートではかわいい赤ちゃんと過ごしながら、父親力を磨いています。


この記事を共有する

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

ブログを読む

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up