Moving towards more unit tests


First attempt at unit testing the check out process - I chose to create tests for the dibs controller. 
For a variety of reasons, quite a lot of refactoring was needed. It was impossible to mock out purchaseorder, so I had to extend the order service to add mapping to a new layer of model objects. This could and should be done by something like AutoMapper in the future.
I removed a lot of protected methods from the base checkout controller, instead moving the methods into separate interfaces, favoring composition over inheritance.
There is a lot of dependency injection "cheating" (getting the dependency when needed instead of at runtime, sneaking in mutability and making dependencies much harder to find). To cater for the unit testing these had to be removed and passed as parameters or injected to the constructor. This, in turn, exposed classes with too many dependencies/ a high level of coupling (GenericPaymentController).
I removed IMarket from DTO (OrderViewModel) to be able to create the model.
Xhtmlstring is a bother! The properties of its type need to be virtual to be able to test anything related to it at all. The IFragmentParser stuff really should be handled some other way.

All in all, few tests are added at this point, but the solution is at a stage where it's beginning to be testable. As usual, when writing the tests, interfaces pop up all over the place, exposing both hidden and blatant coupling. IMO the changes are needed, for the the solution to be maintainable, but someone should really have a good look at this before merging. There's no reason to believe I haven't introduced any hidden (or blatant) bugs.