= Why Static Classes are Pure Evil =
Static Classes are those classes that allow you to access functionality from anywhere in your app, without fuss or bother.
The above - because both the class and method definition are marked static means that anywhere in your application, you can write something like:
presto_all_taken_care_of_in_one_line._dbbackuphelper.doabackupeverysixmonths}
Static Means Ether
What the static method just allowed you to do was, like a magician, conjure out of the ether a card/class that allowed you to call a method on it. No messy wiring, no responsability…all handled for you. It just 'happened'.
Isn't that wonderful?
Magic means Boom
Not really. It would have been wonderful if all had gone to plan, but unfortunately, the app was deployed with a misspelt AppSetting, it wasn't able to find the connectionstring, and the whole blew up. There was no way of knowing this, as the method was called only every six months…
Cutting Ether
The problem is the ether – the fact that you have no idea how to replace the either parts of the operation – the invoking method, or the invoked service/static method – with a Mock test replacement.
To unit test something, one can only do so with Mock services that can side step the problems of Integration Tests, that require the whole beast to be up and running. As integration tests are 2 orders of magnitude more expensive to run that unit tests, you can see that mocking is a preferred solution.
In other words, you need to test things up early.
How about when bootstrapping?
That's what the DI is doing. It's essentially stating that you have to convert the Static classes back into an instance class, bootstrap an IoC with a binding definition of it against a contract, and later either use a ServiceLocator or DI to get the service implementation.
That way , one can replace – in the bootstrapper – the service implementation with a mock implementation, at will.
Neato. I'll have to come back to edit this essay later.