Stop designing for Testability?

Neal emailed around this article at work the other day and it sparked me off on a little rant. I thought I'd repost it here for the hell of it..

Its an interesting article and i think the author definitely has a point.

One of the benefits of TDD is that it forces you to decouple your code and use better OO design - in order for you to test the necessary parts you have no choice but to build a better design into your code.

This is definitely a positive factor - but looking at the process of TDD (red, green, refactor) the main benefit, or the benefit that it seems designed to achieve, is to speed up the feedback cycle. That is, speed up the time between writing code and knowing that the code worked.

One of the key tenets of TDD is to write enough code to make the tests pass - adding a DI framework and abstract factory just so that we can test easily seems to go against that.

The fact that writing tests first can pinpoint areas of tight coupling and high dependency is still important. But, as the article suggests, is it really necessary to develop, say, an abstract factory so you can run your tests, when in actual fact your application only requires only one concrete implementation of a set of classes in order to be "just good enough"?

If we used something like TypeMock to provide an AOP approach to testing then it wouldn't necessarily mean that our design would suffer, rather we would make design decisions solely based on the application domain requirements.

It does sound very plausible - although it would be interesting to see what other people in the TDD community think - personally I think atm that the need for the extra infrastructure to support our tests is the biggest drawback to developers in our team (D&I)from picking up and running with it. The simpler we can keep it, the less resistance we will get.