コード カバレッジは、おそらく最も物議を醸すコード メトリクスです。80% のコード カバレッジに到達する必要があると言う人もいれば、それは表面的なものであり、テストの品質については何も言わないという人もいます。( Jon Limjap の「単体テストの妥当なコード カバレッジ % とは (およびその理由) は?」に関する適切な回答を参照してください。)
人々はすべてを測定する傾向があります。彼らは比較、ベンチマークなどを必要としています。
プロジェクトチームは、テストがどれだけ優れているかという指針を必要としています。
では、コード カバレッジに代わるものは何でしょうか? 「このコード行に触れた」以上のことを示す良い指標は何でしょうか?
本当の代替手段はありますか？
コードの品質 (または品質の欠如) を示す有用なメトリックを探している場合は、次のメトリックを調べる必要があります。
これらは、.NET メトリックおよび依存関係マッピング ユーティリティである NDepend が提供できる主要なメトリックのほんの一部です。私は最近、コード メトリクスを使って多くの作業を行いました。これらの 4 つのメトリクスは、最も有用であることがわかったコア キー メトリクスです。ただし、NDepend は、遠心性と求心性結合、抽象性と不安定性など、他にもいくつかの有用なメトリックを提供します。これらを組み合わせることで、コードの保守性 (および、NDepend がゾーン オブ ペインまたはゾーン無駄。）
.NET プラットフォームを使用していない場合でも、NDepend メトリック ページを参照することをお勧めします。そこには、開発しているプラットフォームに関係なく、これらの指標を計算するために使用できる有用な情報がたくさんあります。
プロジェクト中のコード カバレッジの傾向を監視するのはどうですか?
他の多くの指標と同様に、1 つの数値だけではあまり意味がありません。
たとえば、「Checkstyle ルールへの準拠率が 78.765432% である」場合、問題があるかどうかを判断するのは困難です。昨日のコンプライアンスが 100% だったら、間違いなく困っています。昨日が 50% だった場合は、おそらく順調に進んでいます。
時間の経過とともにコード カバレッジがどんどん低くなっていくと、私はいつも緊張します。これでいい場合もあるので、チャートや数字を見ると頭がオフにならない。
ところで、ソナー ( http://sonar.codehaus.org/ ) は、トレンドを監視するための優れたツールです。
コード カバレッジを単独で使用してもほとんど意味がありません。不要なコードを探している場合にのみ、洞察が得られます。
これを単体テストと一緒に使用して 100% のカバレッジを目指すと、「テスト済み」のすべての部分 (すべてが正常に行われたと仮定) が単体テストで指定されたとおりに機能することがわかります。
技術設計/機能設計から単体テストを作成し、100% のカバレッジと 100% の成功したテストを使用すると、プログラムがドキュメントに記載されているように機能していることがわかります。
必要なのは優れたドキュメント、特に機能設計だけです。プログラマーは、その特定の分野の専門家でない限り、それを書くべきではありません。
これについては言及されていませんが、コードまたはメソッドの特定のファイル（バージョン管理履歴を確認することによる）の変更量は、テストが不十分なコードのテストスイートを構築している場合は特に興味深いものです。頻繁に変更するコードの部分にテストを集中させます。後で使用しないものは残してください。
原因と結果の逆転に注意してください。テストされていないコードを変更することを避け、テストされたコードをさらに変更する傾向があるかもしれません。
シナリオカバレッジ。
100% のコード カバレッジが必要だとは思いません。テストによると、単純なゲッターとセッターは時間の無駄のように見えます。
コードは常に何らかのコンテキストで実行されるため、できるだけ多くのシナリオをリストして (問題の複雑さによっては、場合によってはすべて)、それらをテストすることができます。
例：
// parses a line from .ini configuration file
// e.g. in the form of name=value1,value2
List parseConfig(string setting)
{
(name, values) = split_string_to_name_and_values(setting, '=')
values_list = split_values(values, ',')
return values_list
}
これで、テストするシナリオがたくさんあります。それらのいくつか：
正しい値を渡す
リスト項目
null を渡す
空の文字列を渡す
不正な形式のパラメーターを渡す
name=value1 や name=,value2 のように、先頭または末尾にコンマを付けて文字列を渡す
最初のテストだけを実行すると、(コードによっては) 100% のコード カバレッジが得られる場合があります。しかし、すべての可能性を考慮したわけではないので、その指標だけではあまりわかりません。
経験則として、欠陥注入率はコード歩留まりに比例し、通常は両方ともレイリー分布曲線に従います。
ある時点で欠陥検出率がピークに達し、その後減少し始めます。
この頂点は、発見された欠陥の 40% を表します。
単純な回帰分析を進めると、ピーク後の任意の時点で製品に残っている欠陥の数を推定できます。
これは、ローレンス パットナムのモデルの 1 つの構成要素です。
とにかく高いテスト カバレッジ率が良いことである理由について、ブログ記事を書きました。
私は、コードの一部がテストによって実行される場合、コードのこの部分によって生成された結果の有効性がテストによって検証されることを意味しないことに同意します。
それでも、コントラクトを頻繁に使用してテストの実行中に状態の有効性をチェックしている場合、テスト カバレッジが高いということはとにかく多くの検証を意味します。
コード カバレッジの価値は、テストによって実行された内容をある程度把握できることです。「コード カバレッジ」という言葉は、ステートメント カバレッジ、たとえば「自分のコード (行単位) がどれだけ実行されたか」という意味でよく使われますが、実際には 100 種類以上の「カバレッジ」があります。これらの他のバージョンのカバレッジは、コードを実行することの意味をより洗練された視点で提供しようとしています。
たとえば、条件カバレッジは、条件式の個別の要素のうちいくつが実行されたかを測定します。これは、ステートメント カバレッジとは異なります。MC/DC の「変更された条件/判定カバレッジ」は、すべての条件式の要素が条件式の結果を制御するためにすべて実証されているかどうかを判断し、FAA によって航空機ソフトウェアに対して要求されています。パス カバレッジは、コードを介して実行された可能性のある実行パスの数を測定します。これは、パスが本質的にコード内のさまざまなケースを表すという点で、ステートメント カバレッジよりも優れた尺度です。これらの手段のどれを使用するのが最適かは、テストの有効性についてどの程度懸念しているかによって異なります。
ウィキペディアでは、テスト カバレッジのさまざまなバリエーションについてかなり詳しく説明しています。 http://en.wikipedia.org/wiki/Code_coverage
おそらく、単体テストでカバーされた（触れられた）コードを測定するだけでなく、アサーションがどれほど優れているかを測定します。
実装が簡単な指標の 1 つは、Assert.AreEqual
Assert.AreEqual2 番目のパラメーターとして渡されるオブジェクトのサイズを呼び出して測定する独自の Assert 実装を作成できます。
SQLite は非常によくテストされたライブラリであり、そこからあらゆる種類のメトリックを抽出できます。
バージョン 3.6.14 の時点で (レポート内のすべての統計は SQLite のそのリリースに対するものです)、SQLite ライブラリは約 63.2 KSLOC の C コードで構成されています。(KSLOC は、数千の「コードのソース行」、つまり空白行とコメントを除くコード行を意味します。)比較すると、プロジェクトには 715 倍のテスト コードとテスト スクリプト (45261.5 KSLOC) があります。
最後に、最も重要なことは、考えられる指標のどれもが、「すべての要件を満たしている」という単純なステートメントほど重要ではないということです。（ですから、それを達成する過程でその目標を見失わないでください。）
チームの進歩を判断する何かが必要な場合は、個々の要件を定める必要があります。これにより、何かを指して「これは完了、これは未完了」と言うことができます。それは線形ではありません (各要件を解決するには、さまざまな作業が必要になります)。それを線形化できる唯一の方法は、問題が他の場所で既に解決されている場合です (したがって、要件ごとの作業を定量化できます)。