Tripping over logs: A story of Unity - Part 6

Submitted by Robert MacLean on Tue, 01/06/2009 - 19:06
Intro

The final post in the series :) Get the code here, read comments on unit testing with DI, thanks, references and further reading!

This is a multi-part series as such here is the series guide in case you are looking for the rest of the series:

This is just a final post to wrap up the series, you really should use the above links to get the actual value out of it.

Download the Final Code

You will need 7-Zip to open it.

My view on Unit Testing with DI

What excited me about DI initially is that it makes testing and in particular unit testing, so much better. The problem faced with any system you want to test is that if it is tightly coupled you can’t unit test, you can only do integration testing. By following DI, you are forced into a loosely coupled architecture which means that you can very easily test your individual components.

Let me give you a real world story on this, which involved the enterprise system I mentioned in the very first post. It read from system A, did processing and wrote to system B. The fact it was tightly coupled meant that I couldn’t even fake a message into the system, I had to generate real messages in system A and watch the flow of those messages. After a long time I dropped MSMQ between system A, the processing and system B to enable me to fake messages but even then it wasn’t great as I needed to re-write so much code to talk to these new interfaces. Lastly the processing took many hours to run to completion so proper end to end testing took days, and if a crash occurred certain processes needed to be started from scratch again.

If I had used DI for the system the first thing I could’ve done is written up two mock interfaces and swopped with real ones out using the config. This would mean I could simulate messages simply. System B was in fact MSCRM which I couldn’t run on my machine (laptop running Windows XP at the time) so being able to mock the interface to it could’ve meant that I could’ve worked on the processing engine without MSCRM being needed (i.e. a VM or server).

Next the tightly coupling of methods meant that the process had to run it’s time, but if I had implemented DI I would have each of the individual components of the processing separated out and would be able to have tested them individually. Yes, end to end processing would still be needed but I could’ve saved days of testing with this.

I haven’t actually done enough to write a post on this specific topic, so maybe once I have done more I will be more sure or maybe I will just tell you I was wrong.

Thanks, References and Further Reading

First off thanks to you, the reader, for spending time on this series and I hope you drop me a mail/@rmaclean/comment if this has helped you or you have any questions.

That said I could not have done with without a great posts I found on this subject - so here is my references:

Note that Unity is an implementation of this, there is a lot of them out there. Scott Hanselman has a list at  http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

Lastly I could not end this series without a link to the definitive theory on DI, by Martin “wolfman” Fowler - Inversion of Control Containers and the Dependency Injection pattern. This is a must read for everyone.

The other must read is Jacob Proffitt (http://theruntime.com/blogs/jacob/Default.aspx) who is a .NET expert/guru etc… but is not a fan of DI. The reality check you will get from him should help balance the DI fan-boy crowds out.