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.モックを返すようなモックを普通に作らないから、セットアップコードは簡単になる。 もひとつ重要なメリットは、このアプローチが”重大なアーキテクチャーの境界がなにか”を考えて、ポリモフィック・インターフェースを設計するようになる。 ・自分でモックを書く モックツールを使う場合は、”なるべく軽く” |
投稿 >