私はあなたの人の何人かがあなたの毎日の開発プロセスに、オブジェクトの模擬（JMock、NMock、RhinoMocksのようなフレームワークをユニットテストフレームワークと提携）を組み込んでいることに興味があります。あなたの経験は何ですか？オブジェクトのモッキングは広範囲に使用されていますか？
私は、GIS（地理情報システム）プラットフォームの上に展開しています。このプラットフォームでは、データの処理方法のほとんどが関連しています。そのデータオブジェクトモデルは非常に複雑です（多くの多くのクラスとインターフェイス、すべてのCOMベース）ので、模擬することは非常に困難で厄介です。この場合、テストスイートを作成するときに、mockingが大きなオーバーヘッドを招きます。似たような状況にある人がいるのだろうか、まったく嘲笑して（あなたがどんな状況であっても）あなたのために働くのだろうかと思います。
私が作業した最近のプロジェクトでは、単体テストアプローチでモックオブジェクトを広範囲に使用しました。このプロジェクトは100％Javaで、中程度のサイズ（約10万行の非コメントコード）でした。これはSwingベースのデスクトップアプリケーションでした。ユーザーインターフェイスロジックをテストするための唯一の効果的な方法は、模擬オブジェクトを使用して自動テストのための実際のSwingユーザーインターフェイスクラスを代用できるMVCバリアント設計でした。また、データアクセスレイヤー（Hibernate/DAO）のテストでは、モックを頻繁に使用しました。
ユーザーインタフェースでは、モックは簡単かつ簡単に作成できました。また、アプリケーション（Fowler Passive View）のデザインは簡単にモックを取り入れました。これは、データアクセス層のテストに使用されるモックでは当てはまりませんでした。しかし、私はそれが明らかに努力の価値があったと言うことができます。実際、「努力」の大部分は、個々のモックを作成するために開発者がやらなければならない作業を最小限に抑える再利用可能なソリューションを考え出すことに焦点を合わせました。 GISデータレイヤーを簡単にモックアップできるように、あなたの状況に掘り下げてアプローチする時間を取ることをお勧めします。つまり、各クラスを手動でモックアップするだけです。いずれにしても、モックに依存する自動化ユニットテストを実行する能力は有益です。
私の状況では、モックの仕事は本当にいいです。しかし、私はPythonを使用しています。これは非常に動的なので、多くのことがテストに関わっています。
あなたのような状況では、アプリケーションが主にデータ駆動（私が見る限り）である場合、モックはそれほど有用ではないかもしれません。ちょうどデータを渡して、それが出てくるのを見ているだけで十分です。私はちょうどアプリケーションがを十分にモジュール化したであることを確認するので、このアプローチは適度に小さいコンポーネントに適用できます。
モッキングは、ある種のプロジェクトで役立ちます。しかし、時には嘲笑は非常に時間がかかり、そのROIは低いです。
Sharepointをテストしようとすると、モックが唯一の方法であり、typemockだけが密閉クラスを模擬することができます。
私の場合、モッキングは非常に広範囲に使用されています。モックは、通常外部依存関係を持つクラス用です。ネットワーク、データベース、ファイルシステム。モックが使用されていない場合は、これらのいずれも試験にフレーク性を導入する可能性があります。
多くの偽のデータが存在するため、書き込みにコストがかかる模様がある場合は、事前に入力されたデータオブジェクトを定数として設定し、それらをテストで使用するか、わずかに変更したコピーを使用できます。このようなデータオブジェクトに外部依存関係がある場合は、2つの懸案事項を分離する方法でリファクタリングすることもできます。
Dave Boumanは、ArcObjects関連のユニットテストで使用するMocksのコミュニティライブラリを作成する試みを開始しました。彼のブログと、このSVNリポジトリは、ユニットテストのGISシステム
http://blog.davebouwman.net/CategoryView,category,Unit%2BTesting.aspx
http://svn2.assembla.com/svn/arcdeveloper/TestingUtilities/trunk/
に関連したすばらしい情報を持っています