はじめに
継続的インテグレーションは開発プロセスに欠かせないものであり、最近ではコードカバレッジチェックをビルドオートメーションに組み込もうとする傾向が強まっていますが、開発チームは一体どれくらいのカバレッジ率（ソースコードに対し、どれだけ詳細にテストが行われたかを示す割合）を目標にすればよいのでしょうか。コードカバレッジ重視派の人々の中には、75%という人もあれば、85%という人もあり、100%という人もいます。
私たちがあるプロジェクトでカバレッジ率のベースラインを測定したところ、この開発チームの目標値はそれよりずっと低くせざるを得ないことがわかりました。私は、ジョーゼフ・ヘラーの小説『キャッチ=22』に出てくるキャスカート大佐のように、部隊の兵士の目標出撃回数が達成されそうになるたびに目標回数を引き上げていくようなことはしたくありませんでした。
ヨッサリアンはがっくりとうなだれた。「じゃあ、僕はどうしても50回出撃しなきゃいけないのか」
「55回だ」ダニーカ軍医は言った。
「55回？」
「55回出撃せよ、というのが大佐の今度のご希望だよ」
――ジョーゼフ・ヘラー著『キャッチ=22』より
そこで、あやふやな目標値を設定するのではなく、漸進的（ぜんしんてき・少しずつ段階を踏むこと）に向上させていく手法を採用することにしました。この手法を成功させるには、各ビルドは前回成功したビルドと同じかそれ以上のカバレッジに到達する必要があります。小さな前進をいくつも積み重ねることで、最終的に大きな品質向上を達成しようと考えました。
この記事では、CoberturaとApache Antを使って、コードカバレッジの漸進的向上を実践する方法について説明します。
ユニットテスト、コードカバレッジ、継続的インテグレーション
ユニットテスト、コードカバレッジ、継続的インテグレーションは、いずれも推奨技法として広く認められています。実際、ほとんどの開発者は、ユニットテストを行うことを信奉しています。念のため、まだ改心していない人のために、Googleの研究ディレクターであるPeter Norvigの言葉を引用しておきましょう。
コードのユニットテストを作成する必要がないと思うなら、その理由をすべて紙に書いてみるといい。書き終わったらその紙を入念に見直そう。それが終わったらその紙は捨てて、いずれにしてもユニットテストを作成すること。
けれども、そのテストコードは誰がテストするのでしょうか。つまり、作成したテストコードが十分であるかどうかはどうやって確かめるのでしょうか。これはとても大切な情報です。というのも、作成したテストで実行されないコードこそ、注目すべき部分だからです。1つの解決策は、コードカバレッジツールを使用してテストで実行されるコードの割合を調べ、それから通常の統合プロセスにカバレッジチェックを組み込むことです。カバレッジチェックが失敗すれば、ビルドも失敗するようにします。
漸進的向上の手法を実践するために、私はコードカバレッジツールとしてCoberturaを採用しました。このツールには、シンプルでよく出来ている、4つのAntタスク用インターフェイスが備わっているからです。これらのタスクの1つはcobertura-checkで、これを使用すると、要求するカバレッジ率にコードが到達しない場合にビルドを失敗させることができます。たとえば、次のAntターゲットでは、カバレッジ率が80%を下回るとビルドが失敗します。
<target name="coverage_check"> <cobertura-check totallinerate="80"/> </target name="coverage_check">
ただし、行数の割合をこのようにハードコーディングする代わりに、現在のチェックの目標カバレッジ率として前回のビルドの結果を使用することにします。これを行うには、2つのコアAntタスクを使用していくつかのCoberturaタスクを変更します。
ここで行数の割合、分岐数の割合、その他のカバレッジ測定値を測定するかどうかは気にしません。目的は達成済みのレベルを達成することであり、目標を絶対値で設定したり、どのカバレッジ率測定基準を使うかの詳細を検討することではありません（Coberturaの使用方法については、ここを参照してください。cobertura-checkタスクに該当するタスクのないツールを使用する場合は、Antのfailタスクを検討してください。ただし、その場合はカスタムのconditionを作成することが必要になります）。
