投稿‎ > ‎

モックはいつ使うの?

posted Jul 18, 2014, 6:23 PM by Zhang Wenxu   [ updated Jul 18, 2014, 6:29 PM ]
http://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
モックオブジェクトは非常に強力なツールであり、モックオブジェクトを使うと、主に二つ便利のことができる:依存性の分離とオブジェクト内部検査。但し、どの素晴らしいツールでも同じが、モックもそれなりのコストを払わないといけない。だから、いつ、どこまでモックオブジェクトを使うのか?コスト/便利のトレードオフはどこにあるか?まず両極端のケースを見てみよう。
・モックを一切使わない
モックを一切使わず、大規模Webアプリケーションをテストするとしたら
 ・テスト実施時間が非常に長い
 ・テストのカバレージが低い
 ・テスト範囲外のシステムの失敗起因で、テストが失敗しやすい
すなわち、モックを使わないと、テストが時間かかる、網羅性が低い、壊れやすい。これらの問題は、モックを使えば解決できるじゃないと、と思うが、モックでもモックの代償がある。
・モックが多すぎる
同じ大規模Webアプリケーションに対して、今度はすべてのクラスをモックして、テストするとしよう。どの問題がある?
 ・皮肉な状況であるが、殆どのモックシステムはリクレクション(reflection)より実現されているので、それが実は結構遅くなる。
 ・すべてのクラス間のやり取りをモックするとしたら、列車事故列車事故”とはgetThis().getThat().getTheOther()のようなスタイルのメソッド連鎖のことだ。)より、下記二つ問題が起きやすい。
  1.セットアップコードが異常に複雑になる
  2.モック構造が緊密に詳細な実装に依存しているため、実装が変更したら、多くのテストが失敗してしまう
 ・モックのため、ポリモルフィックのインターフェースが強要される。
結局、モックを使いすぎると、テストが遅くなり、壊れやすい、複雑になる。アプリケーション設計まで被害が及ぶ。
・ちょっとよいモックとは
ちょっとよいモックは、明らかに上記二つ極端なケースの間にあるに間違いない。但し、どこか?私の経験則は下記2点に尽きる。
 ・重大なアーキテクチャーの境界をモックする、境界以内は、モックしない
  例えば、データベース、Webサーバー、外部サービスをモックする。このやり方のメリット:
  1.テスト実行が速い
  2.境界以外のコンポーネントがモックされたので、そちらが失敗したり、設定変更したりしても、テストに影響しない
  3.モックしたコンポーネントが失敗したシナリオも簡単にテストできる
  4.境界跨がる有限状態マーシンのすべての分岐をテストできる
  5.モックを返すようなモックを普通に作らないから、セットアップコードは簡単になる。
もひとつ重要なメリットは、このアプローチが”重大なアーキテクチャーの境界がなにか”を考えて、ポリモフィック・インターフェースを設計するようになる。
 ・自分でモックを書く
  モックツールを使う場合は、”なるべく軽く”
Comments