単体テスト

参考文献

単体テストの考え方 / 使い方 Vladimir Khorikov (著)、 須田智之 (翻訳)

単体テストとは

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

良い単体テストとは

  • 退行（リグレッション）の保護
  • リファクタリングへの体制
  • フィードバックの容易さ
  • 保守性の高さ

単体苞におけるプログラムの依存

  • システム内依存 ≒ プロセス内依存
  • システム外依存 ≒ プロセス街依存

※ データベースはプロセス外依存だがシステム内からのみ利用されるのでシステム内依存と考える。

テスト・ダブル

テスト・ダブル を参照。

良いテストを実現するためのトレードオフ

  1. 退行（リグレッション）の保護：なるべく多くのコードを実行
  2. リファクタリングへの体制：観測可能な振る舞いのみテスト（実装の詳細をテストしない）
  3. フィードバックの容易さ
  4. 保守性の高さ

2 は犠牲にできない。
4 は 1 〜 3 から独立。

よって 1 と 3 のトレードオフ。

単体テストと統合テスト

単体テストはドメインモデルを検証し、統合テストはドメインモデルとプロセス外依存とを結びつけるコードを検証します。 p253

※ すべてのプロ背うがい依存をモックに置き換えた場合はテスト・ケース間で共有される依存はなくなり、他のテスト・ケースから隔離された状態を維持できるので単体テストと考えて良い。

観測可能な振る舞い

対象のメソッドが簡素k可能な振る舞いの一部になるのかどうかは、どれがクライアントなのか、そしてクライアントが達成したいことはなんなのかによって変わります。p253

観測可能な振る舞い の中には外部依存への振る舞いも含まれます。

例） API とのコミュニケーションは外部依存でテスト・ケースも共有していると考えられる（すなわち統合テスト対象）。
ただし API とのコミュニケーションをモックすれば単体テストと考える。

学派

ロンドン学派

テスト対象となるコードを他のコードとお互いにやりとりできないように隔離することを提唱しています。不変依存を除くすべての依存をテスト・ダブルに置き換えることで隔離を実現しようとする

古典学派

テスト・ケース間で共有される依存に対してのみテスト・ダブルを使う。p131

テスト・ダブル

  • モック：外部に向かうコミュニケーションを模倣。副作用あり（観測可能）
  • スタブ：内部に向かうコミュニケーションを模倣。副作用なし

スタブは決して検証してはならない。 p135

実装の詳細の検証になりリファクタリング体制がなくなる。

COS （ Command Query Separation ）の原則

すべてのメソッドは、コマンドかクエリのどちらかになるべきであり療法の性質をもつべきでない。p138

コマンド => モック スタブ => クエリ

観察可能な振る舞い

公開・非公開はメソッドのアクセス修飾子で完全にわけられる。公開メソッドのみテストする

観測可能な振る舞いとは

観測可能な振る舞い（ observable behavior ）は以下のどちらか。p141

  • クライアントが目標を達成するために使う公開された「操作」。操作とは計算したらい、副作用を起こしたりするメソッド
  • クライアントが目標を達成するために使う公開された「状態」。状態とはシステムの現時点でのコンディションのこと

上記に該当しないものが 実装の詳細

コードが観測可能な振る舞いなのか否かの判断はクライアントは何なのか、そしてそのクライアントが目標としていることはとしていることは何なのかということによって変わることです。p141

システム内コミュニケーションは実装の詳細になる。
システム間コミュニケーションは実装の詳細にならない。