「Ode To Code」の中で、K Scott Allen氏は、ユニットテストでモックオブジェクトを使うのは合理的なことだと勧めて(source)、モックオブジェクトのフレームワークを使うことについて(source)彼の考えを述べている。
Allen氏は、モックについてもっとも一般的な誤解しそうなことについて鋭い議論で始める。
この記事は、実際のテスト駆動開発のモックオブジェクト(source)の役割に結び付けて続いている。
Allen氏は、モックについてもっとも一般的な誤解しそうなことについて鋭い議論で始める。
ユニットテストで使うのが難しいリソースで相互関係をシミュレートする必要があるときだけモックオブジェクトが役に立つと誤解する人がいます。それは、例えば、SMTPサーバーで通信するオブジェクトのようなものです。これは本当ではありません。そして、Colin Mackay氏が書いたモックの記事を参照する(source)。そこでは、モックが役に立つという共通のシナリオを挙げている。
Allen氏は、それから上記のリストでさえ少し近視眼的かもしれないとほのめかし、彼のメッセージの要点に迫る。そして、「test double(テスト代役)[モック]はテストでコードを分離したいときに役に立つ」とさらに一般化して主張する。簡単に言うと、Allenによれば、ビジネスコンポーネントのテストを他のコンポーネントすべてから独立させてモックを使う。テストでコンポーネントは次のことに依存する。「A」が「B」を使い、「Aユニットテスト」は「B」の状態にかかわらず、「A」が動かない場合のみ動かなくなるべきである。
- 実オブジェクトは決定されていない振る舞いを持つ。
- 実オブジェクトは設定するのが難しい。
- 実オブジェクトはトリガーするのが難しい振る舞いを持つ。
- 実オブジェクトは遅い。
- 実オブジェクトはユーザインタフェースである。
- 実オブジェクトはコールバックを使う。
- 実オブジェクトはまだ存在しない。
この記事は、実際のテスト駆動開発のモックオブジェクト(source)の役割に結び付けて続いている。
「役割をモックせよ、オブジェクトをモックするな(PDF・英語)」の著者はモックが次のようなものだと言います。
「オブジェクトが果たす役割に基づきシステムでタイプを識別するための技術」であり、「特に今分かるのは、モックオブジェクトのもっとも重要な利点は、私たちがもともとインタフェースの発見と呼ぶものであるということです。」
Allen氏は、JMock(source)、EasyMock(source)、NUnit(source)などのモックオブジェクトのフレームワークを使うことについて短い議論で締めくくる。要約すると、モックオブジェクトのフレームワークを効果的に使うのは大変だが、そのフレームワーク自身はむしろ簡単であるというのが彼の主張である。
チェックする価値がある関連した議論がTDD Yahooグループに出たばかりである。こちらで見てみよう(source)。