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