Mocks
Posted by edc73 on June 26, 2008
So, I’ve been tapped to do a presentation at work on using mocks for unit testing. Not a big deal really, I introduced some examples of using Rhino Mocks to do unit tests on our data layer code over a year ago. This led to a some interesting patterns in our code structure, combining command and template patterns, resulting in a single class for each query/save operation. Overall, I was very happy how it all turned out.
Now our focus is on testing the business layer. That also turned out to not be so bad since the business service allowed for some dependency injection.
But as I start getting closer to the presentation layer, things aren’t behaving so well. So I’m looking at refactoring in different ways:
1. Create test versions of classes that inherit the object under test. Let the test version override factory methods and have them return doubles/fakes/mocks at test time. My main concern is that the virtual methods will get abused in production code.
2. Create a more structured service locater factory, let it’s methods default to returning the types you’d expect in production, but allow other types to be registered for unit tests. Worried about issues with constructors/initialization logic here.
3. Use an Inversion of Control (IoC) container such as Windsor to manage dependencies. I haven’t played with this at all yet, but my gut feel is that we have way too many objects to define in a config file. Also worried about constructor/initialization logic. Obviously, I need to play with this to get a better feel for things.
In the end, I’m sure all of these are valid options, and will just have to see which tool to use in each situation.
I’ll try to get some samples written up soon to clarify the different options I’m considering
