このコードを参照してください:
TicketStoreService fakeTicketStoreService =
MockRepository.GenerateMock<TicketStoreService>();
fakeTicketStoreService.Expect(service => service.DoSomething(Arg.Is(new Guid()))
.Return(new Guid());
fakeTicketStoreService.DoSomething(Arg.Is(new Guid()));
fakeTicketStoreService.VerifyAllExpectations();
DoSomething
これは、NOインターフェースから継承する自動生成クラスの非仮想メソッド呼び出しであることに注意してください。したがって、一般的な知識によれば、それは機能しないはずです。しかし、そうです。
問題は、これを実行できる唯一の(非商用の)フレームワークであるということです。
- Rhino.Mocksが機能し、検証も機能します
- FakeItEasyは、デフォルトのコンストラクターが見つからないと言っています(おそらく間違った例外メッセージ):
No default constructor was found on the type SomeNamespace.TicketStoreService
- Moqは、正気で理解しやすいものを提供します。
Invalid setup on a non-virtual (overridable in VB) member: service=> service.DoSomething
- Nsubstituteはメッセージを出します
System.NotSupportedException: Cannot serialize member System.ComponentModel.Component.Site of type System.ComponentModel.ISite because it is an interface.
Moqを除いて、フレームワークで何が起こっているのか本当に不思議に思っています。「ファンシーな新しい」フレームワークも最初のパフォーマンスに影響を与えているようです。おそらく、Typeキャッシュを準備してシリアル化する一方で、RhinoMocksは、再帰なしで非常に「スリムな」モックを作成できます。私はRhinoMocksがあまり好きではなかったことを認めなければなりませんが、ここではそれが輝いています..残念ながら。
それで、それを新しい(非商用!)モックフレームワークで動作させる方法、またはRhino.Mocksから(実際に使用する6つのパラメーターのどれがどのように異なっているかを説明する)正しいエラーメッセージを取得する方法はありますか? ?そして、Rhino.Mocksがこれを達成できるのはなぜですか?明らかにすべてのモックフレームワークが、具体的なクラスが与えられた場合にのみ仮想メソッドで機能できると述べているのに?
* Extract&Overrideなどの代替アプローチやJustMock / TypeMock / Molesなどのランタイムプロキシモックフレームワークや新しいFakesフレームワークについて話して、議論を狂わせないでください。これらは知っていますが、このトピック以外の理由から、あまり理想的なソリューションではありません。