モッキングフレームワークを選択する主な要因は何ですか？

私は単体テストでオブジェクトを使い始めたいと思っています。優れたモックフレームワークがたくさんあるようです。

1. 異なるフレームワークには異なるターゲットオーディエンスがいますか？
2. 自分の状況に合ったフレームワークを選択する際に考慮すべき要素は何ですか？

異なるフレームワークには異なるターゲットオーディエンスがいますか？

はい。マイクロソフトのようないくつかのフレームワークモグラ、TypeMockアイソレーター、およびJustMockは、あなたが何でも模擬できるようにすることができます。これらのモックツールは、一般に、既存のレガシーコードでそれらを使用したい開発者にとっては、よりテストしやすい設計にリファクタリングできない可能性があるため、より優れています。*

伝統的に、テスト可能なデザインは、コードベースは、したがって、のような伝統的なモックフレームワークインタフェース、抽象クラス、仮想メソッド、シールされていないクラスなどのリベラルに活用する必要があることを意味する部品番号とRhinoMocksもコードでの作業は、テスト駆動開発、依存性注入を使用して開発し、他のそのような概念。ところで、テスト可能なコードだけでなく、メンテナンス可能なコードも得られるため、依存性注入を使用することを強くお勧めします。

自分の状況に合ったフレームワークを選択する際に考慮すべき要素は何ですか？

• 開発アクティビティ。MoqやRhinoMocksなどのツールは非常にアクティブで人気があるため、最新のツールです。
• オープンソース対。コマーシャル。この比較に典型的なさまざまな長所と短所を考慮してください。費用、サポートなど
• 成熟。ツールはどのくらい新しいのですか。ベータ版（Microsoft Molesなど）ですか、またはいくつかの安定したリリースがありますか？たとえば、レガシーコードの場合はMolesが好きですが、それに対処する必要のあるいくつかのバグがあり、対処されるまで待機する予定です（次のリリース2011年11月）。
• ドキュメンテーション。単体テスト、モック、自動モックなどを扱った書籍やブログがいくつかあります。さらに、ツール自体のドキュメントはどの程度優れていますか？
• 構文。各ツールには、同じことを言う独自の方法があります。どちらがより適しているかを確認してください。
• スピード。CLRプロファイリングを使用するツール（TypeMock、Mole、JustMock）は、従来のツール（Moq、RhinoMocks）よりもかなり遅くなる可能性があります。多くの単体テストを蓄積しているため、この速度の低下は問題になる可能性があります。経験則では、テストに1秒あたり1/10を超える時間がかかる場合は遅すぎます。
• コミュニティサポート。他の開発者は、モッキングツールに拡張する（または賛辞で動作する）他のツールを作成していますか？ありMoq.Contribの（テスト書き込み時間のスピードアップに役立ちます）部品番号に自動あざける機能を追加したプロジェクトが。さらに良いことに、AutoFixture、AutoFixture.AutoMoq、AutoFixture.AutoRhinoMocksがあります。これにより、自動モックと匿名変数の作成も可能になります。

^{* 従来のテスト（およびモック）ツールで使用できるコードにテストなしでコードをゆっくりとリファクタリングする方法については、「レガシーコードを効果的に使用する」を参照してください。}

部品番号のチュートリアルは TypeMockアイソレーター、RhinoMocks、およびMOQ：いくつかの特定のツールに関連して、これを論じ冒頭背景、哲学、そして論争の右側のセクションがあります。Moqを説明するために書かれているため、当然少し偏っていますが、モックフレームワークのいくつかの違いを理解しようとすると、非常に役立つことがわかりました。

C＃Mocking FrameworksのこのSOスレッドに対する応答も有用であることがわかりました。ほとんどの場合、ユーザーが実際に役立つと思われる1つのモックフレームワークを参照しますが、プロキシベースのモックとプロファイラーベースのモックについて議論するHaraldVからの応答があります。

また、オンラインで比較チャートを見つけることができました。2009年からのものなので、最新かどうかはわかりません。TypeMockとコールバックに関する情報が古いことを示すコメントが少なくとも1つありますが、グラフは、現在の状態を確認するためにレッグワークを行う必要がある場合でも考慮すべき問題を提起するのに適している場合があります： RhinoMocks、Moq、NMock、とTypeMock比較チャート

Google Codeには、簡単なコード比較のための複数のモックフレームワークのテストケースを使用したプロジェクトがあります： mocking-frameworks-compare

1. 使いやすさ。一部のフレームワークには、より高度な使用法があります。例えば、 MOQは、ラムダの使用が期待を符号化することを可能にします。一部の古いライブラリはこれをサポートしていません。
2. 速度。ライブラリ全体を実行するのに何時間もかからないように、各ユニットテストは高速でなければなりません。一部のモックフレームワークには、静的に生成されたモックがあり、高速です。他のフレームワークは実行時に動的にコードを生成しますが、これは遅いです。
3. サポート。修正プログラムで積極的にサポートされ、リリースされた新しいバージョンの.NETをサポートするように更新されたフレームワークが必要です。
4. 力。私が研究したモックフレームワークのほとんどは、パワーの点ではほぼ同じです。注目すべき例外が1つあります。Microsoft Molesでは、「密閉型の非仮想/静的メソッド」のモックが可能です。これは、私の知る限り、他のモックフレームワークではサポートされていないものです。

私のチームでは、Microsoft Molesを選択しました。これは、＃2、＃3、および＃4で大幅に勝ちますが、ほとんどの選択肢より慣用的ではなく、＃1でローエンドです。