レガシーコードからの脱却 まとめ 11.12 – 11.12.1

11.12 実践しよう

11.12.1 テストを仕様として使うための7つの戦略

内容

テストを文書のようにすることで生きた仕様になる。
そのための7つの戦略を紹介する。

戦略説明
テストを文書のように扱えるようにするテストのコードも、マジックナンバーをハードコードせずに意味がわかる変数名にする
意図がはっきりわかるヘルパーメソッドを使うセットアップの処理や、そのほかの機能を独自のヘルパーメソッドでラッピングすることで、個々のテストの重複を排除しつつも、異なるセットアップオプションを用意できるようになる
何が重要なのかを明らかにする1と似ている。マジックナンバーをハードコードせずに変数で読めるようにして、意図するところをわかるようにする
実装ではなくふるまいをテストする具体的な実装に合わせてテストするのではなく、テストメソッド名を表すことをテストする。
悪い例:testConstructor 。単純すぎる。
良い例:testRetrievingValueAfterConstruction 。何をテストしたいのかがわかる。
モックを使ってワークフローをテストするアサーションは値やふるまいをテストできるが、ワークフローやオブジェクト間の相互作用はテストできない。
これはモックを使ってテストする。
書きすぎない微細に記載することは簡単だが、意味が同じテストは重複である。
例えば、境界値とその間の値の場合、その間の値のパターンは無尽蔵にあるが、実施するのは1つでよい。それ以外は実施した1つのテストと意味が同じだ。
重複したテストは削除する。
正確な例を使う実際の使われ方を実行することによって、コーディングを開始する前に、矛盾や設計上の問題が明らかになり、早期に対処できる

学び

  • プログラマでない人でも読めるように書くべし
  • 重複は省くべし
  • 相互関係のテストはモックを使うべし
  • ふるまいを明確にテストすべし

学びを活かすアイディア・行動

  • 現場のユニットテストのコーディング規約づくり

kiyoshi.saito@tttsunagari.jp

アプリ開発をメインにWebアプリ開発をやってるフリーランスエンジニアです。

Leave a Reply

Your email address will not be published. Required fields are marked *