ガード条件を使ってると単体テスト仕様書が書きやすい

実装パターン

一過性の人気が過ぎ去ったので、またいつものようにボチボチ更新していきます。
またそのうち人気の記事が書けたら良いなぁ。

実装パターンの読書感想と共に現場で思ったことを書く。

実装パターンは、プログラマなら誰でも知ってる

”当たり前のコーディング”に名前をつけたものだ。

和訳版 実装パターンの87ページに書かれている「ガード条件」というパターンは、

単体テストの仕様書を書くにあたっても便利だ。

例として挙げられているのは以下の2つのコードだ。
見比べてみると、読みやすさの違いが分かる。

void initialize(){
    if(!isInitialized()){
        ・・・・
    }
}

void initialize(){
    if(isInitialized())
        return;
    ・・・・
}

1つ目は、elseがどこにあるかを探しながら続きを読む事になる。
2つ目は、最初の条件はクリアしている前提で、続きのコードを読むことができる。

沢山の条件があるルーチンの単体テストを書いていると、
対象コードの分岐を探すのがめんどくさくて嫌になる。
重要な仕様上の分岐をガード条件で分けていれば、
単体テストのパターンが洗い出しやすいと感じた。

テストファーストでやってれば、そんなこと考えなくても済むんじゃ、、、とか。

アレな現場なもんで。