This weblog post argues that IoC should be used in moderation, and for purposes of unit testing in particular can be replaced with reflection - i.e., instead of expressing your class's dependencies in constructor arguments or properties for the IoC container to fill, express them through private variables, make them self fulfilling ("private _myThing = new Thing();") and use reflection to change their values during unit testing.

I am just starting to get serious mileage out of IoC, Castle.Windsor in particular, and also the ObjectBuilder stuff in CAB. I am really liking this style of programming, and really do notice an improvement in how easy it is to set up unit tests and keep dependencies under control.

In a way, I recently moved to IoC - that's why I like to have all my unit tests in-class. Using reflection to set dependencies in fields in an object under test is way more cumbersome and error prone than Mocking some interfaces and passing them to the constructor, or implementing the interfaces with some test classes, and using those (both of which I have to assume you were doing anyway - I know I was.)

I don't like the having-important-code-in-XML part, but the containers I have used so far have not been overly complicated. It's a small price to pay for the structure and modularity it lends you applications.

Source: Getting rid of IoC
Originally published on Sun, 10 Sep 2006 22:55:34 GMT