# 第2章

- 単体テストを「少量のコード（1単位のふるまい）」を「短い実行時間」で「（他のテストケースから）隔離された状態で実行される」ものと定義する
  - 8章の先取りになるが、統合テストは上記の定義に **あてはまらないテスト** ということになる
- デトロイト学派は古典主義で、本番コードと同じように依存クラスなどを準備する
  - 共有依存関係であるDBなどはモック化する
- ロンドン学派はモック主義で、依存クラスはすべてモック化する
  - Enumやconstは不変のためモック化しない
- pp44-45の図が参考になる

## デトロイト学派的隔離: p37

- テストケース同士を隔離すること
  - 1つのふるまいを隔離する
- テストケースの干渉を防ぐためにプロセス外依存（DBなど）をモック化する
  - 依存先クラスなどはモック化しないでプロダクションコードをつかう
  - プロセス外依存を **モック化しない** テストはIT（Integration Test、統合テスト、結合テスト）などより上位のテストで行う
  - ロンドン学派からみると統合テストのようにみえる
- バイブルは『テスト駆動開発』 [^TDD-by-example][^テスト駆動開発]

### pros

- 大きなまとまりとしての動作は検証しやすい

### cons

- 依存関係の解決が大変
  - 依存クラスの依存クラスの依存クラスの……依存クラスを用意しなければならない
    - その場合はそもそもの構造が問題であることもある

### デトロイト学派的統合テスト

- 上述した単体テストの定義から外れるテスト
  - 2つ以上のふるまいを同時にテストする場合
  - 時間がかかるテストの場合

## ロンドン学派的隔離: p29

- テストケースと依存先を隔離すること
  - 1つのクラスを隔離する
- 隔離のためにモックを多用する
  - たとえば、依存先のクラスはすべてモック化する
- バイブルは『実践テスト駆動開発』 [^GOOS][^実践テスト駆動開発]

### pros

- 1クラス1テストなので問題個所の発見が簡単になる
  - 1テスト≠1テストケース
- 依存関係の解決が（比較的）簡単
  - 全部モック化するので

### cons

- テストコード量が増える
- プロダクションコードとの結びつきが強い
  - モック化するので、振る舞いの再現のためにコードの詳細を知る必要がある
    - プロダクションコードの依存先が変わるとテストコードも修正しなければならない
      - テストコードの書き方によってはデトロイト学派でも同じな気もする
- モック化することで保守性が下がる
  - プロダクションコードに変更があってもモックは変更されないので、既存コードのテストは通ってしまう
    - テストコードの更新忘れがあっても気づくのが遅れたりする
  - テストコード→プロダクションコードの順に修正すればそれで解決する？

### ロンドン学派的統合テスト

- 依存先クラスをモック化せずにするテスト

* * *

## 感想など

著者的にはデトロイト推し？デトロイト学派スタイルの利点が詳細に書いてあるのに対して、ロンドン学派スタイルは問題点や課題のほうが詳細に書いてある印象を受ける。



[^TDD-by-example]: [Kent Beck, Test-Driven Development: By Example, Addison-Wesley Professional, 2002](https://www.google.com/search?q=9780321146533&tbm=bks)
[^テスト駆動開発]: [和田卓人訳, テスト駆動開発, オーム社, 2017](https://www.google.com/search?q=9784274217883&tbm=bks)
[^GOOS]: [Steve Freeman and Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley Professional, 2009](https://www.google.com/search?q=9780321503626&tbm=bks)
[^実践テスト駆動開発]: [和智右桂 髙木正弘訳, 実践テスト駆動開発, 翔泳社, 2012](https://www.google.com/search?q=9784798124582&tbm=bks)