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