【失敗例3】ソースコードカバレッジの罠にハマる
単体テストで計測されるソースコードカバレッジは、テストの進捗や、どの程度テストが実施されたのかを表す指針として有効です。しかし、カバレッジにこだわり過ぎることによって、工数が増大し、バグが多く残ってしまい、せっかく工数を割いて単体テストをやっているのにメリットが感じられないといった経験はありませんか？
なぜソースコードカバレッジの罠にハマってしまうのでしょうか？
【原因】1．カバレッジを100％にするために工数がかかった
単体テストのゴールを「カバレッジ100%」や「すべてのメソッドをテスト」と設定することがあります。しかし、それにこだわり過ぎると、単体テストの実装が難しい箇所のカバレッジを上げるために、テストコードの実装に多くの時間を割き、予想以上に工数がかかってしまいます。
【原因】2．カバレッジ100％を達成したが、後工程でバグが多発した
カバレッジが単体テストのゴールになっていると、ついついテストはカバレッジを上げれば良い、と思ってしまいがちです。そのため、テストケースにもカバレッジを上げるためだけのものが実装され、本来行われるべきテストが行われず、バグを見落とすことがあります。これではせっかく単体テストを実施し、カバレッジも計測しているのに品質が上がりません。
対策としては、以下が挙げられます。
【対策】1．カバレッジを100％にするために工数がかかった
一般的な対策
限られた時間で効果的なテストを行うためには、カバレッジにこだわり過ぎず、テスト対象を絞り込むことも有効な方法です。
では、どうやってテスト対象を絞り込めばいいのでしょうか？ 例えば以下の基準でテスト対象を絞り込みます。
テストが必須
- ビジネスロジック（MVCのModel部分）
- 新規コード、追加、修正コード（保守開発の場合）
テストを検討
-
以下のいずれかに当てはまるコード
- 複雑なコード、大きなコード
- 多くのプログラムから参照されるコード
- 変更が頻繁にあるコード
テストから除外
-
実際に操作してテストしたほうが効率的にテストできる部分
- 画面表示部やGUIと密接に関わっている箇所など
例えば、全体の80％をカバーできているプロジェクトで、残り20％の単体テストがやりづらい部分に時間をかけるのであれば、アプリケーションを動かして行うテストでカバーする、手動でテストを行う、というのもひとつの方法です。
さらにJtestによる対策「テスト全体でカバレッジを計測」
単体テストの対象から除外した箇所に対しては実際にアプリケーションを動作させてテストを行います。Jtestでは、アプリケーションを動作させた場合でもカバレッジを取得することができるため、テストの抜け漏れがないか確認できます。さらに単体テストのカバレッジと合算することもできるため、異なるテストでもプロジェクト全体のカバー率を見える化することができます。
【対策】2．カバレッジ100％を達成したのに、後工程でバグが多発した
一般的な対策
はじめに、バグには種類があり、大きく分けて2つのバグがあることを知る必要があります。
- NullPointerExceptionなどのランタイムエラー
- 目的通りにプログラムが動作しない仕様に関するバグ
単体テストは2番目の「目的通りにプログラムが動作しない仕様に関するバグ」を早期に発見し、対処することが主な目的です。そのため、正しくテストを行うためには正しい順序、方法でテストを行う必要があります。
例えば以下の順序・方法で行います。
| テスト手法 | テストの目的 |
|---|---|
| ブラックボックステスト | 仕様通りに動作するかを確認するテスト |
| ホワイトボックステスト | 実装したコードを網羅的にテストすることで、すべてのコードが動作することを確認し、堅牢性を高めるためのテスト |
目的に合わせたテストを行うことで、単体テストの効果を発揮できるようにします。
さらにJtestによる対策「カバレッジを上手に使う」
単体テストは「目的通りにプログラムが動作しない仕様に関するバグ」を早期に発見することが目的ですが、期待通りのテストが行われているか、テストに漏れが発生していないか、確認を行うべきです。
Jtestのカバレッジアシスト機能を使うと、Jtestが実行されていない処理を見つけて警告をレポートしてくれるので、テスト漏れを防ぐことができます。
まとめ
単体テストには明らかなメリットがあることを、多くの開発者やプロジェクトは認識しています。しかし、せっかく導入した単体テストがうまく運用に乗らなかった、今も苦労している、といった声があることも確かです。単体テストのメリットを享受するためには失敗例を知り、対策を立てることが重要です。
さらに、失敗を回避するために商用ツールのJtestを使うことも選択肢のひとつです。冒頭にも書きましたが、Parasoft社の調査によると、Jtestの単体テストアシスタントを使用している顧客からのデータでは単体テストの労力が50％も削減されています。
同社の最近の調査では、開発者の作業時間の約40％が単体テストに使われているそうです。10日間の実稼働日の開発スプリントで考えると、4日間はテストに使われることになります。つまり、この開発スプリントの例で見ると、4日かかっていたテストが2日で終わることになるため、工数削減や早期リリースを実現できます。
Jtestは工数だけでなく、テンプレート作成や処理フローの監視などさまざまなアシスタント機能によって、単体テストを成功に導きます。単体テストで苦労している、うまくいかなかった経験がある、という方はぜひJtestをお試しください。
Jtestの無料体験版を入手！
Jtestの無料体験版を配布しております。以下のリンクからダウンロード可能です。
