プログラミング

ユニットテストの「カバレッジ」についてまとめてみる

最近ユニットテストの「カバレッジ」について勉強する機会があったので、今回はそのカバレッジについて簡単にまとめてみます。

テストカバレッジとは

テストにおける確認が終わった部分の割合(テストの網羅率)のこと。

テスト全体に対して「これくらいカバーしてる」的な指標だったり、「テストを全部やると、これだけ確認できるはずで、今はこれだけの確認が終わってる」という目安にもなります。

英語で「coverage」は「(影響を及ぼす)範囲」を意味する。

テストの種類

システムのテストの種類には以下の4つが一般的です。

  • 単体(ユニット)テスト:クラスや関数の単位のプログラムのテスト
  • 結合テスト:単体(ユニット)テストで検証したプログラムを組みわせて行うテスト
  • 機能テスト:結合したプログラムを1つの機能として行うテスト
  • ステムテスト:システムが仕様通りに動くかを検証するためのテスト

そして単体(ユニット)テストは以下のようにさらに細かく分類できます。

  • 機能確認テスト:1つのモジュールが設計書や仕様書通りに動作することを確認するテスト
  • 制御フローテスト:プログラムの論理構造に沿って「命令」や「分岐」などが実行されるかを確認するテスト
  • データフローテスト:データや変数が「定義」「使用」「消滅」の順に行われているかを確認するテスト

テスト方法

単体(ユニット)テストの手法には「ホワイトボックステスト」が用いられ、これは「システムの中身を理解した上で、それらを意識しながら行うテスト」のことです。

ホワイトボックステストを行うにあたり、論理構造(処理の流れや実行順序)を視覚化する必要があります(可視化ツールなどでコードを視覚化してもいいが、Too much すぎる気はしてる、頭の中で論理構造を構築してテストコードに落とすくらいでいい)。

ちなみにシステムの内部構造を意識しないテストに「ブラックボックステスト」というものがあります(白もあれば黒もある)。

ホワイトボックスのカバレッジ基準

カバレッジ基準とは、テストにおいて着目する「要素」のことを指します。

これはカバレッジを出すのに何を基準にするか、という決めごとのようなものです。

ホワイトボックステストにおけるカバレッジ基準には以下の種類があります。

  • 命令網羅 (Statement Coverage) (C0):すべての命令を少なくとも1回は実行するテストケース
  • 分岐網羅 (Branch Coverage) (C1):判定条件の真・偽を少なくとも1回は実行するテストケース
  • 条件網羅 (Condition Coverage) (C2):判定条件が複数ある場合に、それぞれの条件が真・偽の場合を組み合わせたテストケース
  • 複合条件網羅 (Multiple Condition Coverage) (MCC):判定条件のすべての可能な結果の組合せを網羅し、かつ、すべての命令を少なくとも1回は実行するテストケース

どのカバレッジ基準を使用するかは、コードの精度やテストケースによって様々でケースバイケースな部分があります(だいたいは C0, C1 が使われてる印象)。

テストカバレッジは100%を目指す?

まず「カバレッジが高ければソースコードの品質が高い」というのは誤りです。

ソースコードの品質の良し悪しに関わらず、テストケースが適切に設定されていない場合(バグを上手く捉えらないテスト)はカバレッジが高く算出されてしまいます。

また、カバレッジの数値を上げる「労力」(カバレッジを100%に近づける作業)はカバレッジの数値に対して指数関数的に増加していることが報告されています。

We also found that the test effort increases exponentially with test coverage, but the reduction in field-reported bugs increased only linearly with test coverage. This suggested that for most projects the optimal levels of coverage are likely to be well short of 100%.

via: https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/100-code-coverage-worth-cost

カバレッジを計測する目的は「テストが十分に網羅されていないコードを検出すること」であり、カバレッジの数値を高くすることだけに執着することは費用対効果が低いです。

カバレッジの数値を100%にする作業よりも「テストケースのレビューに時間を割く」方が費用対効果が高いです。

目指すカバレッジの目標値は概ね「80%台後半か90%台」が望ましく、50%以下の場合は問題があるので見直しが必要です。

カバレッジ100%はテストの完了条件ではなく「努力目標」とすることが望ましく、カバレッジの数値に対して盲目的になってはいけません。

参考記事

記事内の写真出典元

Photo by David Travis on Unsplash

ABOUT ME
maechan
ベンチャー、フリーランス、スタートアップを経験。 開発業務、人事業務に従事していました。 現在は農業系スタートアップ企業でエンジニアとして働いています。 リモートワークをしているノマドサラリーマンです。茶道とワークアウトが趣味です。
こんな記事もおすすめ

COMMENT

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です