mock.Stub().Return() を使用して Rhino Mocks のモックの動作を変更できる場合、そもそもなぜスタブが必要なのですか?
常に MockRepository.GenerateMock() を使用すると、何を失うのでしょうか?
スタブの代わりにモックを使用することの大きな利点の 1 つは、すべてのテストで同じインスタンスを再利用して、テストをクリーンで簡単に保つことができることです。
moq フレームワークも同様に機能します...モックとスタブに異なるオブジェクトはありません。
(ファウラーの記事「モックはスタブではない」へのリンクで回答しないでください)
Rhinoはもう開発されていないことに注意してください1。新しいフレームワークは、このモックスタブの違いを完全に排除し、テストダブルに単一の用語を導入します。
モックフレームワークの進化は、テストケースのコンテキストに応じて別々の異なるものを使用するのではなく、「1つの汎用エンティティ」に向かって進んでいるようです。
その分離（モック、スタブ、フェイク）がどのように発生し、それがどのような目的を果たしたかについて詳しく知るには、テストダブルの連続性に関するMarkSeemannの記事を読むことをお勧めします。
極端な例では、実装がまったくないダミーが見つかります。もう一方の端には、完全な本番実装があります。ダミーと本番環境の実装はどちらも明確に定義されていますが、スタブ、スパイ、偽物を特定するのはより困難です。テストスパイはいつ偽物になりますか？さらに、モックは連続体のかなり大きな間隔に生息します。これは、モックが非常に複雑な場合もあれば、非常に単純な場合もあるためです。
Rhinoはモックとスタブを区別していないように見えるかもしれませんが、微妙な違いがあります。たとえば、スタブプロパティゲッターについて考えてみます。
var mock = MockRepository.GenerateMock<IService>();
mock.Stub(m => m.Property).Return(42);
これは、オブジェクトがモックであるときにそれを行う必要がある方法です。一方、スタブは、プロパティのセマンティクスを導入します。これにより、全体が簡単になります。
var stub = MockRepository.GenerateStub<IService>();
stub.Property = 42;
現時点で頭に浮かぶのはそれだけですが、もっとあるかもしれません。しかし、それでも、それらはほんの小さなニュアンスです。
1：2013年5月19日の時点で、これは当てはまらない可能性があります：RhinoMocksの新しい家
ドキュメントにはかなり明確な答えがあります：
モックは、期待を設定できるオブジェクトであり、期待されるアクションが実際に発生したことを確認します。スタブは、テスト対象のコードに渡すために使用するオブジェクトです。あなたはそれに期待を設定することができるので、それは特定の方法で機能しますが、それらの期待は決して検証されません。スタブのプロパティは自動的に通常のプロパティのように動作し、期待値を設定することはできません。
テスト対象のコードの動作を検証する場合は、適切な期待値を持つモックを使用して、それを検証します。特定の方法で動作する必要があるかもしれないが、このテストの焦点ではない値を渡すだけの場合は、スタブを使用します。
重要：スタブによってテストが失敗することはありません。