条件を増やしたときの単体テストのケースづくりについて

下記のようにソースを修正した場合、単体テストでどのようなテストケースが必要になりますか？
下記のようなケースを考えたのですが、ケース③、④は必要ですか？処理Dはインデントしているだけなのでテストの必要ないようにも感じます・・・。
また、これ以外にも実施するべきテストケースはありますか？

ケース① 条件1のみ成り立つとき、処理Aが実行されること
ケース② 条件1,2が成り立つとき、処理B,Cが実行されること
ケース③ 条件1,2が成り立ち、処理Cが正常終了時に処理Dが実行されること
ケース④ 条件1,2が成り立ち、処理Cが正常終了時に処理Dが実行されないこと
ケース⑤ 条件1が成り立たない場合

■修正前

if (条件１ AND 条件2) {
    処理A
    処理B
    処理C
    if (処理Cが正常終了) {
        処理D
    }
}

■修正後

if (条件１) {
    処理A
    if (条件2) {
        処理B
        処理C
        if (処理Cが正常終了) {
            処理D
        }
    }
}

行動規範の内容に同意します

回答1件

ベストアンサー

テスト仕様レビューですか。
私がレビューアならリジェクトです。

条件網羅テスト。条件１と条件２の真偽が網羅されていない

真偽値表を書いて、どの条件の組み合わせのときにどの処理が実行されるのを期待するのか、明確にすること。

条件１	条件２	期待する処理内容
false	false	何もしない
false	true	何もしない
true	false	処理Aのみ実行され、B,C,Dは実行されない
true	true	処理A、処理B、処理Cが実行される

こんな感じで。
このケースだとfalse-trueが抜けやすい、現にあなたも抜けてる。

条件１と条件２は処理C,Dと完全に独立していて、かつC、Dの処理内容に修正がないなら、処理Cが正常終了したら処理D、のテストはスキップしていいかもしれない。

ただしケース③④を実施しなくていいという話ではなく、上の真偽値表に書いた期待する処理内容はテストする必要があります。あくまでCの成否にかかる分岐処理だけの話。
インデントしてるだけとか、そういう理由でテストをカットすることはありません。
（まあインデントやifのカッコが正しく記載されているかどうかはコードレビューの範疇の気がしますが。）
実際のレビュー時なら、レビューイに本当に条件１，２と処理C,Dが独立しているか聞きます。
明確に答えられなかったらきちんと処理内容を把握してないということなので、処理内容を理解するように促して一旦突っ返します。

質問文から読み取れる内容は以上かな。

投稿2018/08/08 22:38