Use NMock to eliminate dependencies during the development cycle and improve code quality
During the development cycle, the scenario often occurs where Developer A is working on a component that depends on a component worked on by Developer B. Of course, B’s component isn’t ready yet. ‘A’ feels hopelessly stuck and ends up twiddling her thumbs waiting for ‘B’ to finish so ‘A’ can complete her code and test it. Management gets fed up with ‘B’ because he’s holding ‘A’ back. Ugliness may ensue, and you can see how the whole thing just ends up bogging down the development cycle.
A great way to get around this problem is for Developer ‘A’ to use a “mock” object to simulate Developer ‘B’s component. For example, let’s say ‘A’ is really a business developer working on a piece of business logic code. ‘B’ is really a data access developer working on a data access component. The business developer uses a mock object to simulate the data access component. The following figure shows this concept:
Note: Of course, to make all of this possible, the business component should always refer to the data access component via an interface. The interface of the data access component must be designed and agreed upon before ‘A’ and ‘B’ go about their work.
Using a mock object brings some other key benefits to the table besides eliminating the dependency of Developer ‘A’ on Developer ‘B’s work.
- If the business developer does not have access to the database on her workstation, she can use a mock object to simulate the database.
- Using a mock object to simulate the data access dependency isolates the business component for the purpose of unit testing. That way, the developer knows that any unit test failures are from the business component, not the data access dependency.
Okay… so that’s the pitch for why you would want to use ‘mock’ objects during the development cycle. It all boils down to improvements in process and improvements in quality. I’ve been pitching those benefits to customers for quite some time now.
There’s one slight annoyance developers might find to using mock objects: They’re on the hook to go through the tedious process of creating them. Plus, with a mock object, what if it actually needs to have some minimal intelligence to simulate the results expected by ‘A’s code? Then the mock object is no longer just a ‘stub’. The result is that the work required to build the mock object makes ‘A’ feels as though she has to implement ‘B’s code!
I never had a good answer for that downside before… until I came across this ‘nugget’ yesterday and had a moment of enlightenment. The ‘nugget’ is the following MSDN article on using an open source tool called NMock by Mark Seemann:
Mock Objects to the Rescue! Test Your .NET Code with NMock
In the article Mark discusses the scenarios I described above and how NMock can help. NMock is a tool that dynamically generates mock objects via reflection at runtime based on the interface of the dependency. NMock even lets you simulate any ‘intelligence’ the mock object needs to have to satisfy the component that depends on it. Mark has all of the details on how it works. But the gist is that it gets the developer off the hook for having to tediously create all of the mock objects.
This article looks like it came out in 2004. If only I had known about it back then, I could have saved myself a lot of trouble!
[Updated] Bill Pierce noted in my comments that another great tool for doing dynamic mock objects is Rhino-Mock. I checked it out over the weekend, and it looks good. I saw that there are a couple of these tools out there. Sure wish I knew then what I know now. :)
