ArcObjectsをモッキングでユニットテストするにはどうすればよいですか？

私はユニットテストの大ファンですが、それでもFGDBを利用して、ArcObjectsフレームワークの使用時にユニットテストを実行するための機能を取得します。

IFeature、IGeometry、IWorkspaceなどのモックに対してうまくモックを使用している人はいますか。そうであれば、それを行う方法の例をいくつか見てみたいと思います。私はあなたがどのようなモックフレームワークを使用するかについては特に気にかけていません。

私が見ている問題は、同じオブジェクトの非常に多くのインターフェース間でスライスしてダイスを作成しなければならないことです。そのため、代表的なモックオブジェクトを作成するオーバーヘッドが非常に大きくなります。

大きなプロジェクトでは、ArcObjectsコードをビジネスロジックから分離するためにうまく管理できました。それは、モックフレームワークを使用していくつかの方法を実現することが可能であっても、すべてを模倣しようとするのではなく、一般的に進むべき道だと思います。

自問してみてください。なぜあなたはあざける必要性を感じるのですか。通常は、抽象化が欠落していることが原因です。小さな責任を考え、巨大で醜いArcObjectモンスターの表面を最小限に抑えます。ArcObjectタイプのいくつかの側面がどこかで必要になるという理由だけで、ArcObjectタイプをドラッグしないでください。

私たちのプロジェクトから具体的な例を1つ挙げます。コードの一部はIMxDocumentに依存しているようです。唯一の理由は、アクティブなビューを更新する必要があることでした。そのため、代わりにIViewRefresherインターフェイスを作成し、それだけを処理しました。モックとテストが簡単です。さらに、コードの意図がより明確になり、誰かがIMxDocumentを使って面白いことを始めようとする誘惑がなくなりました。同じ演習は、多くのArcObjectsコードで実行できます。

また、フィーチャクラスへのすべてのアクセスをタイプセーフラッパーでラップし、ビジネスコードをArcObjectsからシールドするモック可能なコードを再び提供しました。

ArcObjectsのジオメトリタイプの使用についても説明しましたが、現在、これらのインターフェイスをコードで直接使用することを許可しています。（ただし、インターフェースの知識のみが許可され、ジオメトリのすべてのインスタンス化は独自のジオメトリファクトリを使用します。）

要約すると、私はモックの使用を推奨していませんが、ArcObjectsとは異なる抽象化レベルでモックを作成することをお勧めします。

Esriの開発者のためのユニットテスト、彼らはいくつかの投げた、特に以来-デイブBouwmanとブライアンNoyleによってはかなり良い出発点であるコードを見てみ。