Unit Testing Mocking: Mock Builders, NMock vs RhinoMock
I recently started getting pretty big into Unit Testing. I've always done it to some degree, but like most places, when upper management feature creeps a thousand requirements, it's usually unit testing that goes out the window. I don't like it, but that's the real world. But, I have a solution!
Unit Testing through Dependency Injection
I decided I would build Unit Testing capabilities through Inversion of Control so that I could quickly and easily toggle mock testing. Now, there's a lot of mocking tools out there such as NMock and Rhino Mock. I did some extensive research on each, but in the end only chose one and integrated it into my own capabilities.I found a great article on Microsoft's site that discusses Unit Tetsing with mocks at length. I also found a great blog by rob bowley on the subject for you to see:
nMock vs RhinoMocks
I've recently started using RhinoMocks instead of nMock, mainly because it's strongly-typed. However, I've found a few other little treats:
Stubs
In nMock, if you want to stub some method calls on a mocked interface you have to do something like this:
Mockery mockery = new Mockery();
IService mockService = mockery.NewMock();
Stub.On(mockService).Method("MethodA");
Stub.On(mockService).Method("MethodB");
Stub.On(mockService).Method("MethodC");
...
Which is cumbersome and noisy. In RhinoMocks you can do this:
MockRepository Repository repository = new MockRepository();
IService serviceMock = repository.Stub();
...
...and RhinoMocks will ignore all calls to that interface. This is really nice as you generally only test the SUT's interaction with one dependency at a time.
Dynamic Mocks
If you only want to test one interaction with a dependency and ignore all others you can create a dynamic mock.
MockRepository Repository repository = new MockRepository();
repository .DynamicMock();
...
All calls to the mocked dependency will be ignored unless they are explicitly expected (e.g. Expect.Call(mockService.MethodA).....). This is the same as
not
saying mockery.VerifyAllExpectationsHaveBeenMet() in nMock. It's always annoyed me that you have to remember to do this in nMock and I much prefer that the default for RhinoMocks is to fail when encountering an unexpected method call.
Raising Events
nMock does not natively support raising events, which is a pain, but there are ways around it With RhinoMocks it's much simpler.
My Solution for Inversion of Control
I created a solution that blends NMock with my own custom mocker. Why did I choose NMock? Because Rhino Mock, although extremely powerful seems to try to build mocking and unit testing all into itself. I saw this as 2 seperate concerns. In addition, some of the syntax was quite complicated and less intuitive than I would have liked. NMock is pretty simple and straightforward. I used its interface proxy capabilities and then used Dependency Injection to override some of its functionality. Now I'm able to create a simple unit test with one line of code. Or if I want to create a custom mock with custom values, 2 lines of code! If you're interested in a copy of the library, just contact me!
Tuesday, September 23, 2008 9:34:13 AM