私はこれを読みました：http：//martinfowler.com/articles/mocksArentStubs.html スタブとモックについての私の概念は明確です。moq、rhinomocksなどの分離フレームワークの必要性を理解しており、モックオブジェクトを作成するのが好きです。モックとして、期待の実際の検証に参加します。しかし、なぜスタブを作成するためにこれらのフレームワークが必要なのですか。手作りのスタブをロールアウトして、さまざまなフィクスチャで使用したいです。
3 に答える
4
厳密に言えば、いいえ、スタブを作成するための分離フレームワークは必要ありません。実際、Microsoftには、モックではなくスタブのみを生成するスタブフレームワークもあります。
自分で分離フレームワークを作成したことはありませんが、オブジェクトのモックを配置すると、スタブを簡単に作成できるようになります。これが、ほとんど/すべての分離フレームワークにスタブオブジェクトが含まれている主な理由である可能性があります。
最後の文（「手作りのスタブをロールアウトしてさまざまなフィクスチャで使用したい」）に関して、実際に大きなプロジェクトで試したことはありますか？確かに、null許容のboolを返す単一のメソッドを持つインターフェースがあるかもしれません-そのインターフェース用に3つのスタブを書くだけでよく、それはそれほど悪くはありません。
しかし、スタブへの数十のインターフェースとクラスを調べ始めると、すべての異なるスタブを追跡するのは簡単に混乱します。複数のテストで各スタブを使用している場合は、スタブを手書きして脇に置くことを正当化できます。ただし、特定のスタブを1回または2回だけ使用する場合は、簡単にするために、フレームワークによって直接生成された「匿名」スタブとして保持する方がはるかに簡単です。
于 2010-05-23T02:34:07.490 に答える
4
手巻きのスタブがより良いオプションであると判断する前に、Rhino Mocksのようなライブラリを1日か2日使用してみましたか？
@chibacity：ライブラリをモックすることについての全体的な考えは、実装を避けることです。単一のプロパティの値を設定するだけでよい場合は、インターフェイスの実装全体を作成したくありません。次のような呼び出しコード
MyObj obj = MockRepository.GenerateStub<MyObj>();
obj.MyProperty = 33;
私にははるかに簡単に思えます。ダムスタブをパラメータとして渡すだけで、何が起こってもかまわない状況は言うまでもありません（したがって、設定は必要ありません）。
これは、より複雑なシナリオで独自のスタブを展開するべきではないという意味ではありませんが、私の経験では、そのようなケースはまれです。
私の推奨事項は、（Rhinoのような）優れたモックライブラリをそのすべての小さなトリックで使用する方法を学ぶことです。私の賭けは、その存在の理由をすぐに理解することを学ぶことです。
于 2010-05-23T14:15:58.747 に答える
2
しばらくの間モックフレームワークを使用した後、私のコードデザインはまったく異なる傾斜を帯びていることがわかりました。この傾斜は、インタラクションスタイルでより方向付けられているようです。言い換えれば、私は状態よりもメッセージと行動に興味を持つようになります。私のオブジェクトは、スタブを使用するときに発生するようなステートフルオブジェクトではなくサービスになります。スタブを使用すると、状態を他のオブジェクトに渡すことになります。
私にとっての問題は、抽象化レイヤーの作成になります。何かが特定のレベルで相互作用するべきかどうか疑問に思う必要があります。これは、その「最後の責任のある瞬間」を作成するのに役立ちます。そのため、プロデューサーとコンシューマーを持つオブジェクトになります。そして、その間のすべては単なるメッセージチャネルです。
これがお役に立てば幸いです。
于 2010-05-25T19:11:48.240 に答える