読者です 読者をやめる 読者になる 読者になる

TDD(テスト駆動開発)における品質分析

TDDでは、常に動くソースコードが確認できるとか、リグレッションテストが簡単とか、メリットは多いのだけれど、以下のような問題にぶつかることが多い。

  1. テストケースを作成するのに時間がかかる
  2. 仕様を満たしているか分からない
  3. バグ検出密度(バグ件数/開発規模)が分からない

テストケースを作成するのに時間がかかる

テストカバレッジを100%に近づけようとすると、テストコードの規模は、開発対象のソースコードの2〜3倍程度になり、かかる工数もばかにならないんだよね。

ただ、かかる工数は、Excelなどでテスト仕様書を書く従来の方法との比較が必要だろう。従来の方法では、仕様書作成とテスト実施に時間が必要だったわけだけど、工数の大小は、

    • (Excel仕様書)テスト仕様書作成 < (TDD)テストコード作成
    • (Excel仕様書)テスト実施(手動) >> (TDD)テスト実施(自動)

という感じかな。「テスト実施(手動)」の場合、バグ修正などのために少なくとも2〜3回はテストは行われるだろうから、トータルとして考えれば、TDDの方が工数がかからないんじゃないだろうか。

仕様を満たしているか分からない

開発者のスキルに因るところが大きいんだろうけど、テストがパスするかどうかだけじゃ、テストそのものが正しいのかどうか分からない。
以前に、Listを戻り値として返すメソッドのテストで、Listの件数だけで assertEquals をしているテストコードを見たことがある。List中のデータを確認しなきゃ、仕様を満たしているかどうか分からんでしょ。

カバレッジが100%であろうとも、仕様を網羅するようにテストケースを作成していないと、テストの意味がないよね。
これを防ぐには、テストコードのレビューが有効かな。ただ、膨大なテストコードをレビューするのは大変。
Javadocに特定の形式でテスト仕様を書くと、それを抽出してテスト仕様の一覧を作成くれるT-Docletなるツールがあるんだけど、これなんか使うと、レビューが楽になる。

バグ検出密度が分からない

TDDでは、バグ検出密度による品質分析はできない、ということが前提となっているようだ。テスト実施とプログラム作成が並行で進むから、「バグ検出」と言えるタイミングがない。そのため、カバレッジやテストケース数などで品質を分析することが多い。

でも、バグ検出密度は、品質を見るのには良いメトリクスデータだと思うんだよね。バグ検出密度が高すぎれば品質の悪さが懸念されるし、低すぎれば未検出バグが潜んでいる可能性が高くなるので、品質チェックの重点ポイントを見つけやすい。でも、カバレッジやテストケース数だけではそれが見えないんだよね。

こればっかりは、良い策が思いつかない。TDDでバグ検出密度を測定する方法ないかな・・・