Two recent articles that are well worth reading. First, from David Hansson:
And a rebuttal from Bob Martin
I think both articles make some good points. On this issue I tend to agree more with David than Bob.
However, I think one of the main things both positions suffer from is a rather myopic view of testing. The focus is almost exclusively on unit testing. David asserts, I think convincingly, that you can damage your design by contorting it to be testable in the sense of old-school unit testing.
I think the problem is this focus on old-school unit testing. I also assert (without proof for the moment) that unit testing is a fiction. Any test code is always testing more than the strict object of the test. If nothing else you are also testing the run-time support of the programming language you are using. Yes, the test is geared toward a particular aspect of your design or implementation, but the notion of a test running in isolation is illusory.
If instead you look at a test as exercising a portion of a system, but with an eye toward proving out one aspect of it, the need to mock everything to death goes away. You spend your time building up an execution framework that doesn’t abstract away all the implementation details that, in the end, are just as important as whatever the object of your test is.
Building automated tests does not induce design damage. Mocking induces design damage.