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