モックオブジェクトをいつ使うか?

作者 Mike Bria, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年6月19日 午前12時45分

コミュニティ

Agile

トピック

アジャイル技術,

ユニットテスト

タグ

TDD,

Mocks

「Ode To Code」の中で、K Scott Allen氏は、ユニットテストでモックオブジェクトを使うのは合理的なことだと勧めて(source)、モックオブジェクトのフレームワークを使うことについて(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)。

原文はこちらです：http://www.infoq.com/news/2008/06/mocks-q-of-when

• 次へ >