はじめに
ウォータフォール開発において、
単体テストでどこまでしっかりテストするか?
というのは、いつも議論になることです。
考え方として
「命令網羅(処理網羅)」の観点でテストするか
「分岐網羅」の観点でテストするか
「条件網羅」の観点でテストするか
という3つがあります。
テスト方針はよく、C0,C1,C2といった記号で表されるですが、
C0は「命令網羅」
C1は「分岐網羅」
C2は「条件網羅」
になります。
この3つの考え方の違いについて説明します。
説明するためのネタとして、以下のようなプログラムを考えましょう。

週末の過ごし方を決定するプログラムです。
もし天気が「晴れ」なら
夢の国に行きます
パレードがある場合はパレードを見るし、
パレードがない場合は乗り物にのって遊びます。
さらに、夕食は
ストランが空いていればレストランで食事を、
もし空いていなかったら家で食事をします。
もし天気が「晴れ」以外なら
家で過ごします
ざっくり説明

文字背景色が黄色になっているところが条件分岐があるところ、
文字色が赤文字になっているところが実際に行う可能性があることを意味しています。
これをそれぞれざっくり説明するとこんな感じになります。
命令網羅:赤文字の処理を全て最低1回はテストする
分岐網羅:全ての赤文字の処理を通るパターンをテストする
条件網羅:黄色背景の条件に着目して、あり得る条件を全てテストする
命令網羅(C0)
「命令網羅」の観点でテストをするには、赤文字の処理を全て最低1回はテストすればOKです。ですので、
1.晴れでパレードあり、レストランが空いている
2.晴れでパレードなし、レストランが空いていない
3.雨
この3パターンでテストをすれば、命令網羅の観点でのテストは完了です。
分岐網羅(C1)
「分岐網羅」の観点でテストをするには、全ての赤文字の処理を通るパターンをテストすればOKです。ですので、
1.晴れでパレードあり、レストランが空いている
2.晴れでパレードあり、レストランが空いていない
3.晴れでパレードなし、レストランが空いている
4.晴れでパレードなし、レストランが空いていない
5.雨
この5パターンでテストをすれば、分岐網羅の観点でのテストは完了です。
条件網羅(C2)
「条件網羅」の観点でテストをするには、黄色背景の条件に着目して、あり得る全ての条件をテストすればOKです。
もう少し噛み砕いて言うと、まずあり得る条件を全て洗い出して、その洗い出した条件を少なくとも1回は登場させてテストする、ということになります。
条件1[天気]:晴れ・曇り・雨
条件2[パレード]:あり・なし
条件3[レストランの空き]:あり・なし
ですので、
1.晴れでパレードあり、レストランが空いている
2.晴れでパレードなし、レストランが空いていない
3.曇り
4.雨
この4パターンでテストをすれば、条件網羅の観点でのテストは完了です。
まとめ
気づいた人もいるかもしれませんが、
分岐網羅の観点でテストをしたら「曇り」のパターンのテストができていません。
一方、条件網羅の観点でテストをしたら
「パレードあり」かつ「レストランが空いていない」のパターンのテストができていません。
理想を言えば、分岐網羅の観点と条件網羅の観点の両方でテストをするのが望ましいですが、
与えられた工数の中でテストをしないといけませんので、そこはテスト方針を定めたうえで、行うしかないのです。
現実的に、大きなプログラムになってくると、単体テストと言えど、
分岐網羅も条件網羅もどちらも完全にすることは難しいことが多いです。
少なくとも命令網羅はカバーしたうえで、後はどこまでしっかりテストをするのか、
テスターとレビュアーの間(レビュアーがいない場合は各テスター間)で認識を合わせたうえでテストを行うのが現実的ですね。
単体テストについての学習
単体テストは個人的にはシステム開発の中では最も重要な工程の中で
最も面倒くさい工程だと思っています💦💦
ここの手法をしっかり理解して自分の中に落とし込むことが出来ていれば
システムエンジニアとしてはどこに言っても通用できる人材になります。
私としてもかなり色々学習してきましたが、一番役に立っているのが
「経験ゼロでもできるプログラミング現場の単体テスト」という本です。
是非一度読んでみてください。
内容は論理的過ぎず、具体的なテストのイメージが湧きやすいです。
JUnitなどのテストツールの説明も細かくされているので、個人的にはこれだけ読んでおけばよかった感があります。早くこれに出会っていればよかった。
最近のコメント