ウチとこのヒヨコで知らん奴がいたのでメモを残しておく。
検査網羅率(テストカバレージ) ── どんだけテストしたか、の指標。
たとえばこんなコードがあったとしよか:
void f(引数いろいろ...) {
if ( 条件A || 条件B ) {
処理1
} else {
処理2
}
if ( 条件C ) {
処理3
} else {
処理4
}
}
さてこのコードの引数をいろいろとっかえてちゃんと動くかテストするわけだが、
何通りのテストケースを用意すれば"全部テストした"ことになるか。
ここで問題となるのは「何をもって"全部テストした"とみなすか」であるな。
C0: 命令網羅 ステートメント・カバレージ
とにかく通っていない処理がなくなればC0は100%となる。
この例では 処理1,2,3,4 を少なくとも1度通るべし、てこと。
つまりテストケースとしてはたとえば
- 処理1, 処理3 を通るケース
- 処理2, 処理4 を通るケース
のふたつ。
C1:分岐網羅 ブランチ・カバレージ
分岐の全組み合わせをテストすればC1は100%となる。
この例では
- 処理1, 処理3 を通るケース
- 処理1, 処理4 を通るケース
- 処理2, 処理3 を通るケース
- 処理2, 処理4 を通るケース
の４つ。
C2:条件網羅 コンディション・カバレージ
条件式の全組み合わせをテストすればC2は100%となる。
この例では、条件A,B,C があるので
- 条件A = false, 条件B= false, 条件C= false となるケース
- 条件A = false, 条件B= false, 条件C= true となるケース
- 条件A = false, 条件B= true, 条件C= false となるケース
- 条件A = false, 条件B= true, 条件C= true となるケース
- 条件A = true, 条件B= DC, 条件C= false となるケース
- 条件A = true, 条件B= DC, 条件C= true となるケース
の６つ。
※ (DC: Don't Care = どーでもいいってこと)
実コードでは条件式の数がかなり大きくなる。
条件式が10個あったらC2を100%にしようとすれば
最大1024通りのテストケースが必要となり、
とてもじゃないが"やってらんねー"。
なのでテキトーに折り合いつけるわけね。
しかしたとえば条件式５つずつの二本のコードに分割
できるなら、C2を100%にするには32通りをふたつで
64通りのテストケースとなり、これなら全件テストできっかも。
関数を分割するメリットがここにもあるわけな。