ユニットテストのカバレッジについて

4558 ワード
ユニットテスト テスト駆動開発 カバレッジ テスト テスト テキストリンク

テストカバレッジとは

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

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

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

テストの種類

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

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

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

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

テスト方法

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

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

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

ブラックボックステスト - IT用語辞典バイナリ

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

カバレッジ基準とは、テストにおいて着目する「要素」のことを指す。
カバレッジを出すのに何を基準にするか、という決めごとのようなもの。

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

  • 命令網羅 (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%以下の場合は問題があるので見直しが必要である。

テストカバレッジ - Martin Fowler's Bliki (ja)

カバレッジ100%はテストの完了条件ではなく「努力目標」とすることが望ましい。

カバレッジの数値に対して盲目的になってはならない。

参考記事