Notice that there isn't an empty bracket in the end. It will teach you how to use mocks to track dependency collaboration and how to use stubs to control program flow including how to use built in and custom constraints to create more specific mocks and stubs. I think it's the cleanest/most readable technique:Įxpect.Call( () => mock.someVoidMethodWithAParameter(someParamValue)) įor methods that doesn't have any parameters, the following is acceptable:Įxpect.Call( mock.someVoidMethodWithoutAnyParameter) In this course you will learn how to use Rhino Mocks to isolate your tests from the dependencies of the classes you are unit testing. Ayende have a post that addresses this same issue here: Using Expect.Call(void method).įor me, I like using lambda expression the best. Simply will not work as the expect.call expect a non void method. The approach to this test is the basic approach for any test that uses. In Rhino Mocks this call is GenerateStub and we use it to generate all the objects that are interacting with our system under test (the sut variable, in our code). One thing that I haven't discovered until now is how to mock void methods with Rhino mocks. This first test shows the most important call in any mocking framework: the creation of a basic mock object. For those of you who just started in the software development field, I highly suggest to look into mocking framework in general especially when you're interested in doing Test Driven Development. It's a debatable issue to use mocking framework in a unit test, which I'll not touch in this post. Out of those people only a handful believes in using Mocking framework. MockWPC.Raise(x => x.Downloading += null, this, EventArgs.Only a handful of people use unit test extensively. Var mockWPC = MockRepository.GenerateMock() We then tell out Rhino Mock object to raise the Downloading event (in this example with non specific event arguments 'EventArgs.Empty') We use a boolean eventRaised, and (using lambda syntax) create an anonymous event handler for the Propert圜hanged event which sets eventRaised to true if the event is fired. In the example below we want to test that when an IWorkPackageCoordinator raises it's Downloading event that the ViewModel in turn raises it's Propert圜hanged event. - we don't care about the actual delegate that is attached hence theĪnother test that is useful is that the object we are testing performs some action when another object raises an event that it is subscribed to. Tell Rhino Mocks that we expect the following events to be subscriped to IWorkPackageCoordinator mockWPC = (IWorkPackageCoordinator)mocks.StrictMock(typeof(IWorkPackageCoordinator)) MockRepository mocks = new MockRepository() //using mocks to verify property setters. To test this we create a ViewModel and pass it a mock object that has been created for us by Rhino Mocks. In other words: does the ViewModel subscribe to the IWorkPackageCoordinatorevents. The following example is essentially testing that when a new ViewModel is instantiated (the constructor accepts an IWorkPackageCoordinator as a dependency), that the events declared on the IWorkPackageCoordinator instance have been subscribed to (by the ViewModel instance). Sometimes we want to ensure that a given event has been subscribed to. When stubbing a method return value, Rhino.Mocks supports the following syntax: dependency.Stub (s > s.GetSomething ()).Return ( new Order ()) The method signature is generic and therefore you get compile-time type checking that the object you’re returning matches the return value defined by the GetSomething method. There are possible more 'elegant' methods for the below but these are fairly well understandable by someone new to Rhino Mocks or mocking in general.
0 Comments
Leave a Reply. |