カバレッジ100%だからといって、well-testedではない
TotT: Understanding Your Coverage Data by Google Testing Blog
So the correct way to do coverage analysis is:
Step1. Make your tests as comprehensive as you can, without coverage in mind. This means writing as many test case as are necessary, not just the minimum set of test cases to achieve maximum coverage.
Step2. Check coverage results from your tests. Find code that's missed in your testing. Also look for unexpected coverage patterns, which usually indicate bugs.
Step3. Add additional test cases to address the missed cases you found in step 2.
Step4. Repeat step 2-3 until it's no longer cost effective. If it is too difficult to test some of the corner cases, you may want to consider refactoring to improve testability.
Step1. Make your tests as comprehensive as you can, without coverage in mind. This means writing as many test case as are necessary, not just the minimum set of test cases to achieve maximum coverage.
Step2. Check coverage results from your tests. Find code that's missed in your testing. Also look for unexpected coverage patterns, which usually indicate bugs.
Step3. Add additional test cases to address the missed cases you found in step 2.
Step4. Repeat step 2-3 until it's no longer cost effective. If it is too difficult to test some of the corner cases, you may want to consider refactoring to improve testability.
「僕のソースはコードカバレッジが高いから、十分テストしてるのさ」というのはマチガイ。という話。ここではステートメントカバレッジを例に挙げて、たとえテストが100%カバレッジをしていても、見つけられない欠陥があるということを示している。
で、コードカバレッジ解析の正しい手順はこんな感じ。
- 可能な限り広範囲にテストケースを作成する
- 自分のテストカバレッジ結果をチェックする
- 2を元にテストケースを追記する
- 2~3を効果がでなくなるまで繰り返していく
ここでは最小のテストサブセットで最大のカバレッジ(数学的にはcompactか)させようとは思わずに。
そうすると自分のテストケースから漏れていた、想定外のパターンが見えてくる。
テスト容易性(testability)に着目してリファクタリングするもよし。
ある技法によってテストケースを作成し、もれてしまったパターンや重要なパターンなどは追記していく。これ常套手段ですな。HAYST法でもやるやる。
| 固定リンク
この記事へのコメントは終了しました。

コメント