優れたテストスイート

• テストすることが開発サイクルの中に組み込まれている
• コードベースの特に重要な部分のみがテスト対象となっている
• 最小限の保守コストで最大限の価値を生み出すようになっている

単体テストの定義

• 「単体（unit）」と呼ばれる少量のコードを検証すること
• 実行時間が短いこと
• 隔離された状態で実行されること

古典学派の観点における単体テストの意味

• 1 単位の振る舞い（a unit of behavior）を検証すること
• 実行時間が短いこと
• 他のテストケースから隔離された状態で実行されること

共有依存、プライベート依存、プロセス外依存

古典学派およびロンドン学派が考える単体テストの違い

協力者オブジェクト

次の性質を 1 つ以上持つ依存のこと

• 可変である（状態を変えることができる）こと
• まだメモリ上にはないデータの橋渡しをするもの（共有依存）であること

良い単体テストを構成する 4 本の柱

• 退行（regression）に対する保護
• リファクタリングへの耐性
• 迅速なフィードバック
• 保守のしやすさ

「退行（regression）に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」を全て最大にはできない。
「保守のしやすさ」は独立している。
「リファクタリングへの耐性」を犠牲にできないため、他の 2 つでバランスを取る。

テスト・ピラミッド

• 単体テスト -> 迅速なフィードバック
• 統合（integration）テスト -> 2 つの中間
• E2E（End-to-End）テスト -> 退行に対する保護

ホワイト・ボックス・テストとブラック・ボックス・テストの長所と短所

テスト・ダブルの種類

大きく分けてモックとスタブ

観察可能な振る舞い（observable behavior）

以下のどちらかでなければならない

• クライアントが目標を達成するために使う公開された操作
• クライアントが目標を達成するために使う公開された状態

単体テストの 3 つの手法

• 出力値ベース・テスト（戻り値を確認するテスト）
• 状態ベース・テスト（状態を確認するテスト）
• コミュニケーション・ベース・テスト（オブジェクト間のやり取りを確認するテスト）

単体テストの 3 つの手法と 4 本の柱

※ 迅速なフィードバック、退行（regression）に対する保護

隠れた入力と出力の種類

• 副作用: メソッド・シグネチャには表現されていない出力のこと。

4 種類のプロダクションコード

以下の 2 つの観点から 4 つに分類できる

• コードの複雑さやドメインにおける重要性の観点
• 協力者オブジェクトの数の観点

コントローラにおける条件付きロジックの扱い

ビジネス・オペレーションを実施している最中に、プロセス外依存へのアクセスが要求される場合、以下の 3 つの選択肢がある。

• 外部の依存に対するすべての読み込みと書き込みをビジネス・オペレーションの始めや終わりに持っていく
• ドメイン・モデルにプロセス外依存を注入する
• 決定を下す過程をさらに細かく分割する

そのとき、次の 3 つのバランスが取れていることが重要

• ドメイン・モデルのテストのしやすさ
• コントローラの簡潔さ
• パフォーマンスの高さ

ただし、3 つのすべてを備えることは不可能で、2 つまでしかできない。

• 外部の依存に対するすべての読み込みと書き込みをビジネス・オペレーションの始めや終わりに持っていく -> パフォーマンスが下がる
• ドメイン・モデルにプロセス外依存を注入する -> ドメイン・モデルがテストしづらくなる
• 決定を下す過程をさらに細かく分割する -> コントローラの簡潔さを保てなくなる

パフォマーンスとドメイン・モデルのテストしづらさを犠牲にできないので、必ず「決定を下す過程をさらに細かく分割する」必要がある。
コントローラが複雑になっても、管理可能なレベルまで抑える。

解決策

• 確認後実行（CanExecute/Execute）パターンの適用
• ドメイン・モデルの状態を追跡するドメイン・イベントの利用

統合テストの役割

単体テストの性質を 1 つでも損なっているテスト。
コントローラを統合テストで検証する。

2 種類のプロセス外依存

モックのベストプラクティス

• モックの利用は統合テストに限定する（単体テストでは使わない）
• モックに対して行われた呼び出しの回数を常に確認する
• モックの対象となる型は自身のプロジェクトが所有する型のみにする