TDD（テスト駆動開発）における品質分析
TDDでは、常に動くソースコードが確認できるとか、リグレッションテストが簡単とか、メリットは多いのだけれど、以下のような問題にぶつかることが多い。
- テストケースを作成するのに時間がかかる
- 仕様を満たしているか分からない
- バグ検出密度（バグ件数／開発規模）が分からない
テストケースを作成するのに時間がかかる
テストカバレッジを100％に近づけようとすると、テストコードの規模は、開発対象のソースコードの2〜3倍程度になり、かかる工数もばかにならないんだよね。
ただ、かかる工数は、Excelなどでテスト仕様書を書く従来の方法との比較が必要だろう。従来の方法では、仕様書作成とテスト実施に時間が必要だったわけだけど、工数の大小は、
-
- （Excel仕様書）テスト仕様書作成 < （TDD）テストコード作成
- （Excel仕様書）テスト実施（手動） >> （TDD）テスト実施（自動）
という感じかな。「テスト実施（手動）」の場合、バグ修正などのために少なくとも2〜3回はテストは行われるだろうから、トータルとして考えれば、TDDの方が工数がかからないんじゃないだろうか。
仕様を満たしているか分からない
開発者のスキルに因るところが大きいんだろうけど、テストがパスするかどうかだけじゃ、テストそのものが正しいのかどうか分からない。
以前に、Listを戻り値として返すメソッドのテストで、Listの件数だけで assertEquals をしているテストコードを見たことがある。List中のデータを確認しなきゃ、仕様を満たしているかどうか分からんでしょ。
カバレッジが100％であろうとも、仕様を網羅するようにテストケースを作成していないと、テストの意味がないよね。
これを防ぐには、テストコードのレビューが有効かな。ただ、膨大なテストコードをレビューするのは大変。
Javadocに特定の形式でテスト仕様を書くと、それを抽出してテスト仕様の一覧を作成くれるT-Docletなるツールがあるんだけど、これなんか使うと、レビューが楽になる。
バグ検出密度が分からない
TDDでは、バグ検出密度による品質分析はできない、ということが前提となっているようだ。テスト実施とプログラム作成が並行で進むから、「バグ検出」と言えるタイミングがない。そのため、カバレッジやテストケース数などで品質を分析することが多い。
でも、バグ検出密度は、品質を見るのには良いメトリクスデータだと思うんだよね。バグ検出密度が高すぎれば品質の悪さが懸念されるし、低すぎれば未検出バグが潜んでいる可能性が高くなるので、品質チェックの重点ポイントを見つけやすい。でも、カバレッジやテストケース数だけではそれが見えないんだよね。
こればっかりは、良い策が思いつかない。TDDでバグ検出密度を測定する方法ないかな・・・
