まず本物を使い、代役が要るならフェイクを選ぶ。スタブとやり取りの検証は使いすぎるとテストを脆くするので絞る。
| 技法 | 中身 |
|---|---|
| フェイク | 本物と同じに振る舞う軽い実装 |
| スタブ | 戻り値を決め打ち |
| インタラクションテスト | 呼ばれ方（回数・引数）を確認 |
目次
まず本物を使う
本物を動かすテストほど、正しく動いている確信をくれる
- 速く決定的な値オブジェクトなどは迷わず本物
- 遅い・頻繁に揺れるときだけ代役に替える
- 組み立ては本番と同じ DI を通し、代役を差し込める作りに
代役が要るならフェイク
フェイクが守るべきは本物と同じ API の契約
- 作るのは呼び出しの根元（DB の API）に1つだけ
- 本物とフェイクに同じ契約テストを流してずれを防ぐ
- 追従の保守コストに見合わなければ本物を使い続ける
スタブとやり取りの検証は絞って使う
基本は結果の状態を確かめ、やり取りの検証は例外にする
- スタブ多用は実装の詳細が漏れ、変更に弱くなる
- やり取りの検証は状態を確かめようがないときか、回数・順序が問題のときだけ
- 対象は外に副作用を持つ関数（メール送信など）に限る