Christian Gruber氏は(リンク)コードのカバレッジをメトリクスとして使うことに対する(リンク)TDDのスタンスを、時間をかけて明確にしようとしている。彼はカバレッジからわかることとわからないことについて検討し、TDDがどのようにしてその実態に合わせるか、そしてカバレッジを使うための最適なアドバイスは何かについて議論を展開した。
アプリケーションのコードカバレッジは、ちゃんとしたTDDで開発すると非常に高いもの（>80~90%）になるらしい。しかし、アプリケーションのカバレッジが高い値を示しているからと言って、そのアプリケーションがしっかりとしたTDDで開発されたかどうか、それどころかTDDで開発されたかどうかを判断することはできない。そもそもカバレッジは、アプリケーションが十分にテストされたことを示すものとして適切なのだろうか？
Christian Gruber氏のこの議論は、Kevin Pang氏のブログでの同テーマの記事が(リンク)きっかけになっている。Gruber氏は冒頭で、TDDの支持者がカバレッジを「真実を表す唯一のメトリクス」として勧めてはいないことを説明している。それは他にもフィードバックのネタがある場合においてのみ、ある程度使えるものだと言う。彼はPang氏の主張する「（Pang氏）100%のカバレッジは長い間テストマニアの究極の目標になっている」に反論し、「（Gruber氏）高いカバレッジはよくテストされたシステムが持つ望ましい特性ではある。ただし目標はシステムを十分にテストすることなのだ」と主張した。
彼はコードカバレッジ、TDD、そして「十分なテスト」について次の6つの主張をしている。
- カバレッジはしっかりとしたテストが書かれている状況でのみ意味を持つ。役に立たないくだらないテストが書かれることを防ぐことはできない。
- カバレッジはテストが通過した行／分岐を測定しているだけに過ぎない。
- カバレッジはテストが不十分かどうかを示唆するが、十分であることを保証するものではない。
- テスト駆動で書かれたコードは十分なカバレッジを示しやすい。
- テスト駆動で書かれたコードは十分なテストがされていることが多い。作成者はコードの要求／仕様のすべてを形作るテストを書いているからだ。
- 完全なカバレッジは十分なテストに必要なものではない。
Gruber氏はその後、テストツールというよりも設計技術とも言うべきTDDがテストの完全性にどのように寄与するかについて簡単に説明している。さらに、「（TDDの文脈では）カバレッジは、何かが失敗していたり、足りていないことに気づくためのよい方法であるが、それ以外の何者でもない」といい、その点ではPang氏の主張と概ね合意している。
カバレッジの誤用についての警告は新しいものではなく、むしろそれによってより多くの組織がTDDを採用していることのメッセージとも言える（おめでとう！）。そして、いとも簡単に「福音としてのカバレッジ」アンチパターンに陥るのである。
さらにこのテーマについて知りたければ、Jason Rudolph氏(リンク)の最近の記事の「コードカバレッジ分析の実用的な利用法」の段落を読むといい(リンク)。このテーマに関する他の専門家の意見へのよいリストが提供されている。