We're considering switching from Rhino to FakeItEasy for our mocking framework. The main reason is simplicity, in FakeItEasy there's only one way to do things. Rhino has record/playback, AAA, stub, partial mock, strict mock, dynamic mock, etc.
I'm rewriting some of our tests using FakeItEasy to ensure it will do everything Rhino is currently doing for us, and I've encountered something I can't explain and was hoping someone could enlighten me.
In Rhino, I have the following test. The code has been abbreviated.
ConfigurationManagerBase configM开发者_开发百科anager = _mocks.Stub<ConfigurationManagerBase>();
using( _mocks.Record() )
{
SetupResult
.For( configManager.AppSettings["ServerVersion"] )
.Return( "foo" );
}
The unit test to which this code is attached runs just fine and the test passes. I rewrote it using FakeItEasy as follows.
ConfigurationManagerBase configManager = A.Fake<ConfigurationManagerBase>();
A.CallTo( () => configManager.AppSettings["ServerVersion"] )
.Returns( "foo" );
Now when I run the test it fails, but it's because FakeItEasy is throwing an exception.
The current proxy generator can not intercept the specified method for the following reason:
- Non virtual methods can not be intercepted.
That seemed odd, because Rhino has the same restriction. What we think is happening in that while AppSettings is virtual on ConfigurationManagerBase, the indexer property is not. We corrected the problem by changing the FakeItEasy test to read.
NameValueCollection collection = new NameValueCollection();
collection.Add( "ServerVersion", "foo" );
A.CallTo( () => configManager.AppSettings )
.Returns( collection );
I'm basically just trying to understand whether I'm doing something wrong with FakeItEasy or is Rhino performing some "magic" behind the scenes with that indexer?
The following configuration should be similar to what Rhino does if this doesn't work Rhino does something magic:
NextCall.To(configManager.AppSettings).Returns("foo");
var ignored = configManager.AppSettings["ServerVersion"];
精彩评论