第27章 テスティングのパターン

[at-grandpa]

テストを書くことに焦点をあてる。

[at-grandpa]

小さいテスト

• 大きなテストがコケたら、問題箇所を絞り込んだ小さなテストを走らせる
• レッド・グリーン・リファクタリングのリズムは絶対に死守する
  • 途切れかけたらそれは今の歩幅がおかしい
  • 歩幅を調整してリズムを取り戻す
• テストを通すために複数箇所を修正しなければならないときは危ない
• まずはグリーンに戻して、一つ一つのテストを書いて、グリーンバーを維持しよう
• 小さい機能を組み合わせて大きな機能にする

[at-grandpa]

Mock Object(擬装オブジェクト)パターン

• 構築が重いオブジェクトが必要だったら
  • モックを使う
• 使い所
  • DBとか
• モックを使うと、オブジェクトの可視性に留意するようになる
  • コードの結合度を低く抑えることができる
• モックと本物の動きが違う時のリスクはないのか？
  • 本物のリソースが使える時に、モックを差し替えてもテストが通ればok

[at-grandpa]

Self Shunt(自己接続)パターン

• オブジェクトが他のオブジェクトときちんとやり取りしていることをテストしたい
  • テスト対象オブジェクトがやり取りする相手をテストケース自身となるようにする
    • テスト対象が他のオブジェクトを引数として取り入れる場合、テストケースのselfを渡すようにする
    • 必要なメソッドをテストケース自身に定義する
    • こうすることで、テスト対象以外のオブジェクトを作らなくて済む
    • selfがmockのように振る舞う
    • テストケース自身に処理が書かれているので可読性が上がる
      • 普通は、渡すオブジェクトの定義まで遡らないといけない
• インターフェースの抽出が必要になるときもある

[at-grandpa]

Log String(記録用文字列)パターン

• 正しい順序でメソッドが呼び出されていることをテストしたい
  • xUnitでおこなった記録用文字列を使う
• 役立つ時
  • Observer パターンを実装していて、特定の順番で通知が行われていることを検証したいとき
  • Observer パターン
    • Subjectクラスが監視対象
    • Subjectは複数のObserverインスタンスを持っている
    • Subjectクラスの内部状態が変更されたら、Observerの通知メソッドが呼ばれる
    • この通知が特定の順で実施されたかを Log String パターンでテストする
• Self Shunt と 相性がよい。テストケースに書かれたメソッドの順に、記録用文字列に追記すればいいだけだから

[at-grandpa]

Crash Test Dummy(衝突実験ダミー人形)パターン

• エラー処理のテストはどうしたらいいか
  • 普通のテストどおりにするが、例外を発生させるオブジェクトを使うようにする
• 稀な例外条件でもテストは書くべきか？
  • もちろん書くべき
• ファイルシステムの容量がいっぱいになってしまったと想定
  • 実際にテストでそんなことはしない
  • Fileクラスを拡張したFullFileクラスを作る
  • 実際のopenメソッドをオーバーライドし、Exceptionを投げるようにする
  • このFileクラスをテスト対象オブジェクトに渡せば良い
  • なるほどーーーーー

[at-grandpa]

失敗させたままのテスト

• コーディング時間の終わりは、テストが失敗する状態にしておく
• どこから始めるかが明白にわかる

[at-grandpa]

きれいなチェックイン

• チームで開発をしているなら、コードのmerge時は必ずテストが全て通るようにする
• 他の人が作業するときに、グリーンから始められるべきだ

[at-grandpa]

この章で得た知見

• 各テストパターンを知れたのはよかった
• このあたりのノウハウは、実際の業務でつかってみないとだな