明日からできるプロジェクト管理（4）
単体テストの品質をチェックするには
1page｜2page｜3page

高野敦
2006/1/12

● 単体テスト（BlackBox）におけるツール

　単体テスト（BlackBox）において重要なのは、テストが実施されているかどうかとどのテストが失敗しているかが明確になることです。そのためxUnitを利用して単体テスト（BlackBox）を実施し、その結果をレポート化することで単体テスト（BlackBox）をツールが支援します。

　ここではJUnitのレポートについて説明します。

○ JUnitReport

　JUnitの機能を利用します。JUnitについてはいろいろなところで説明されているので説明を省きます。ここではMavenを利用してビルドのタイミングですべての単体テストを実施し、その結果をレポート化する方法について説明します。

　テスト結果レポートを作成するためにproject.xmlに以下のような設定を追加します。

　<report>に以下のコード片を追加します。

<report>maven-junit-report-plugin</report>

　この設定でMavenのsiteゴールを実行するとJUnitのテストを実施し、その結果をレポートとして出力します。FindBugsと同様にJUnitレポートプラグインによるレポートを参照すると、以下の図のようになります。

図5 JUnitレポートプラグインによるレポートを参照すると（クリックすると拡大）

　このレポートでは4つのテストを実施し、1つのテストが失敗しています。
FindBugsの場合と同様にPMは、全体から部分、エラーが起こった個所とブレイクダウンして分析をします。

　 今回のテスト失敗は、testCheckValueCase3というテストメソッドで起こっていることが分かります。このテストメソッドはBlackBoxテストとして定義したテストケースです。仕様では1のときに1を返すことになっていますが、チェックロジックを入れ忘れたために判定が最後まで行われず99を返しているようです。

　このように仕様のとおりにJUnitのテストケースを作成しておくことで、仕様の実装し忘れなどの間違いを防ぐことができるようになります。

　JUnitのテスト結果によってテスト失敗と報告された欠陥は、すべて修正する必要があります。このレポートは定時に行われるべきものなので、その修正が終わるまでテスト失敗と報告されますから欠陥記録を作成する必要はありません。ただし、ナイトリービルドなどを作成している場合はその限りではありません。プロジェクトによって判断されるべき内容です。また、その修正は迅速に終わらせる必要があります。修正することが困難なエラーに関しては、欠陥記録を作成すべきです。欠陥記録に関するツールは次回、説明をする予定です。

● 単体テスト（WhiteBox）におけるツール

　単体テスト（WhiteBox）のポイントはテストのカバーしている範囲が広いことです。この範囲をカバレッジと呼びます。このカバレッジを測るツールがカバレッジツールです。カバレッジツールとしては、JCoverage、EMMA、Coberturaなどがあります。単体テストをJUnitのテストケースとして実施し、そのカバレッジを測る方法がよく取られます。もちろん、結合テストなどの工程でカバレッジが測られることもありますが、多くの場合単体テストでカバレッジが計測されます。ここではJCoverageを紹介します。

○ JCoverage

　JCoverageは、GNU General Public Licenseで提供されるオープンソースのエディションがあるカバレッジツールです。コマンドラインで実行することも可能ですが、ここではMavenを利用し、JUnit単体テストを実施しそのテストカバレッジを測る方法を説明します。FindBugsと同様、project.xmlに以下の設定を行い、siteゴールを実施します。

　<report>に以下のコード片を追加します。

<report>maven-jcoverage-plugin</report>

　また、JUnitの単体テストが失敗しても成功部分のカバレッジを計測したい場合はproject.propertiesにmaven.test.failure.ignore=trueの設定を追加します。

　siteゴールを実行し、FindBugsレポートと同様にJCoverageの実行結果のレポートを参照すると以下のようになります。

図6 全体の結果（クリックすると拡大）

　%lineは行の網羅率（C0）を表していて、%branchは分岐の網羅率（C1）を表しています。この全体結果からは、C0 が72％、C1が67％であることが分かります。それほどカバレッジが高くない場合は、これをブレイクダウンしていきます。この場合はパッケージが1つしかないので、example.utilを選択すると以下のようなレポートが表示されます。

図7 パッケージの結果（クリックすると拡大）

　全体がパッケージに代わり、全体ではパッケージ単位になっていましたが、クラス単位のカバレッジが一覧化されています。この場合は、クラスが1つしかないのでUtilクラスを選択するとクラスレベルのレポートが表示されます。

図8 コードレベルの結果（クリックすると拡大）

　checkValue()メソッドでは32行目、36行目のコードがテストされていません。入力値であるestValueが3のとき、5のときがテストされていません。5の場合は仕様書には書かれていませんでした。実装時にプログラマーへ仕様の追加が直接連絡されたのでしょう。仕様書のテストケースを作っておくことで、このようなことも分かる可能性があります。また、checkString()メソッドはまったくテストされていないことも分かります。これらの結果から、このサンプルのテストコードでは単体テストが不十分です。カバレッジを高める必要があります。

　このようなレポートによってPMは、ソースコードや単体テストの品質を知ることができます。特にビルド時にこのような情報が分かることは、品質を向上するうえで重要です。

　石出さんもこの仕組みを利用してオフショアのソースコードや単体テストの品質を向上させる気になってきたようです。

◎ ソースコードのコミットログから状況を把握する

　筆者は構成管理ツールにSubversionを使うことが多いので利用したことはありませんが、CVSを使っている方はStatCVSプラグインを利用できます。このプラグインはStatCVS-XMLのレポートを出力してくれるので、このサイトにサンプルが紹介されています。

　全体のレポートのLines Of Codeの時系列グラフを見ることで、CVSに登録されているソースコードの推移を確認することができます。また、Author Statisticsを選択するとコミットしたユーザー別のレポートが得られます。このレポートのActivity のグラフを見ることで、コミットの曜日、時間を把握することができます。PMは、就業時間外（休日、深夜）にコミット時間が多い場合に「トラブルプロジェクト」の兆候を見いだすことができます。必ずしもトラブルプロジェクトとは限りませんが、複数の兆候で判断すべきです。このCVSStatの情報は兆候の1つとして利用できます。

　このように何らかの工夫によって「プロジェクトの状態」を把握することが重要です。

3/3

INDEX
明日からできるプロジェクト管理（4） 単体テストの品質をチェックするには
	Page1 ◆ 品質の考え方
	Page2 ◆ メトリクスを計測するためのツール
	Page3 ● 単体テスト（BlackBox）におけるツール

IT Architect 連載記事一覧