I have been hearing about testable code for a long time now. It looks somewhat like this, although I had to cut on the number of interfaces along the way.
We go through a lot of contortions to be able to do something fairly simple, avoid hitting a data store in our tests.
This is actually inaccurate, we are putting in a lot of effort into being able to do that without changing production code. There are even a lot of explanations how testable code is decoupled, and easy to change, etc.
In my experience, one common problem is that we put in too much abstraction in our code. Sometimes it actually serve a purpose, but in many cases, it is just something that we do to enable testing. But we still pay the hit in the design complexity anyway.
We can throw all of that away, and keep only what we need to run production code, but that would mean that we would have harder time with the tests. But we can resolve the issue very easily by making my infrastructure aware of testing, such as this example:
But now your production code was changed by tests?!
Yes, it was, so? I never really got the problem people had with this, but at this day and age, putting in the hooks to make testing easier just make sense. Yes, you can go with the “let us add abstractions until we can do it”, but it is much cheaper and faster to go with this approach.
Moreover, notice that this is part of the infrastructure code, which I don’t consider as production code (you don’t touch it very often, although of course it has to be production ready), so I don’t have any issue with this.
Nitpicker corner: Let us skip the whole TypeMock discussion, shall we?
TDD fanatic corner: I don’t really care about testable code, I care about tested code. If I have a regression suite, that is just what i need.