Unit Test Presentation

So I did my presentation yesterday. The focus morphed a bit from the initial concept. It ended up focusing more on refactoring legacy code to make it testable. While the examples I gave still had some mocking in them, that was not the focus. I really tried to impress upon people the need for small, cohesive methods and classes. We discussed Test Specific Subclasses, Dependency Injection, and some design patterns. We also touched on some general unit test concepts. Overall I was happy with the material I was able to present within the hour time limit. If you were there, what did you think? Did it help or was it information overload?

Castle Windsor

Earlier today I managed to get sample code working that integrated Castle Windsor with ASP.NET MVC.  By creating a custom controller factory, I was able to delegate to Windsor to create the controller.  A side benefit of the custom factory is that there is no more “magic” that converts a call to “service” to the class “serviceController”.  Hopefully I’ll have some time to go further down this path to see if it really ends up helping some of our dependency issues, or if I’m just adding more problem points.  I expect the tough issue will be deciding which classes should go through Windsor and which should stay as they are.

Either way, I’m going to also give it a shot on my home RssReader project.  Since that’s in it’s early stages, should be interesting to see it evolve with Windsor integrated from the get go.

Mocks

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