InfoQ

News

コードカバレッジには要注意

作者 Mike Bria, 翻訳者 菅野 裕 投稿日 2008年11月19日 午前12時51分

コミュニティ
.NET,
Java,
Agile
トピック
ユニットテスト,
アジャイル技術,
Delivering Quality
タグ
Antipatterns,
Code Coverage

Christian Gruber氏は(リンク)コードのカバレッジをメトリクスとして使うことに対する(リンク)TDDのスタンスを、時間をかけて明確にしようとしている。彼はカバレッジからわかることとわからないことについて検討し、TDDがどのようにしてその実態に合わせるか、そしてカバレッジを使うための最適なアドバイスは何かについて議論を展開した。

アプリケーションのコードカバレッジは、ちゃんとしたTDDで開発すると非常に高いもの(>80~90%)になるらしい。しかし、アプリケーションのカバレッジが高い値を示しているからと言って、そのアプリケーションがしっかりとしたTDDで開発されたかどうか、それどころかTDDで開発されたかどうかを判断することはできない。そもそもカバレッジは、アプリケーションが十分にテストされたことを示すものとして適切なのだろうか?

Christian Gruber氏のこの議論は、Kevin Pang氏のブログでの同テーマの記事が(リンク)きっかけになっている。Gruber氏は冒頭で、TDDの支持者がカバレッジを「真実を表す唯一のメトリクス」として勧めてはいないことを説明している。それは他にもフィードバックのネタがある場合においてのみ、ある程度使えるものだと言う。彼はPang氏の主張する「(Pang氏)100%のカバレッジは長い間テストマニアの究極の目標になっている」に反論し、「(Gruber氏)高いカバレッジはよくテストされたシステムが持つ望ましい特性ではある。ただし目標はシステムを十分にテストすることなのだ」と主張した。

彼はコードカバレッジ、TDD、そして「十分なテスト」について次の6つの主張をしている。
 

  1. カバレッジはしっかりとしたテストが書かれている状況でのみ意味を持つ。役に立たないくだらないテストが書かれることを防ぐことはできない。
  2. カバレッジはテストが通過した行/分岐を測定しているだけに過ぎない。
  3. カバレッジはテストが不十分かどうかを示唆するが、十分であることを保証するものではない。
  4. テスト駆動で書かれたコードは十分なカバレッジを示しやすい。
  5. テスト駆動で書かれたコードは十分なテストがされていることが多い。作成者はコードの要求/仕様のすべてを形作るテストを書いているからだ。
  6. 完全なカバレッジは十分なテストに必要なものではない。

Gruber氏はその後、テストツールというよりも設計技術とも言うべきTDDがテストの完全性にどのように寄与するかについて簡単に説明している。さらに、「(TDDの文脈では)カバレッジは、何かが失敗していたり、足りていないことに気づくためのよい方法であるが、それ以外の何者でもない」といい、その点ではPang氏の主張と概ね合意している。

カバレッジの誤用についての警告は新しいものではなく、むしろそれによってより多くの組織がTDDを採用していることのメッセージとも言える(おめでとう!)。そして、いとも簡単に「福音としてのカバレッジ」アンチパターンに陥るのである。

さらにこのテーマについて知りたければ、Jason Rudolph氏(リンク)の最近の記事の「コードカバレッジ分析の実用的な利用法」の段落を読むといい(リンク)。このテーマに関する他の専門家の意見へのよいリストが提供されている。

原文はこちらです:http://www.infoq.com/news/2008/11/coverage-NE-tdd

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

Typemock: その過去・現在・未来

Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。

企業とSaaSの仮想化がもたらすのは、迅速性(アップ)だけではない

この論文では、仮想化やクラウドサービスの複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。

RubyのFiberを非同期I/Oに使うNeverBlockとRevactor

Fiberはユーザに試練を課すことなくこの考えを実装する有益な並行性ツールとして、ライブラリが2つあります。まさにこのためのソリューションとしてあるのがNeverBlockライブラリです。私たちはNeverBlockプロジェクトのMohammad A. Ali氏とRevactorライブラリのTony Arcier氏に話を聞きました。

拡張性に関する悪習慣

システムの保守容易性や拡張性を確保するためのベスト・プラクティスに関する記事は数多くありますが、この記事では避けた方がいい、いくつかの悪習慣(ワースト・プラクティス)を強調します。

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。