Can TDD Taken too far?
Uh oh - one of the uglier side effects of TDD (edit, link removed as the post was taken down) starting to rear it's ugly head.
:edit: Since the aforementioed link was broken (unsure why...) - let me explain what used to be there. Basically, the idea is that developers, when working on projects, are starting to subtly turn away from features that are hard to test. This conversation is not too hard to imagine:
Business User to Development Manager: I would like the app to do foobar.
Development Manager to Developer: Let me run it by the team.
Developer to Development Manager: I don't think we should do it because it will break all of our fitnesse tests/will be hard to unit test/etc.
Development Manager to Business User: We should not do the feature because our developers say it will be to hard to test.
Business User: @#$*))*@#$?
This scenario gets to the core of what I was suspicious about when I first heard of Test Driven Development - namely, that testing would become the tail that wags the dog with respect to software development.
TDD is very important... but you have to make sure that the above conversation, basically, never happens, because each time it does, you essentially tell users that testability is more improtant than what they think is important, which I can assure you, isn't testability. Now of course, testability does lead to something that users indeed do want... in the long term - that being maintainable software that doesn't have bugs. However, there are some scenarios that are near impossible to reliably express in test that business users will demand in requirements. Some examples:
Specification: Correctly determine optimal bundled price set in a reverse auction.
Specification: Correctly determine best search result that user of X/Y/Z type will want to see.
Specification: Determine estimated risk exposure of CDO portfolio.
Specification: Make the website branding pleasing to the eye
... you get the idea. Some requirements are either hard and don't lend themselves to unit testing, are based on subjective criteria, or don't have a correct answer, only a set of possible good ones. The answer is not to not unit test those scenarios - there are elements of them that you certainly can, but it is to understand the limits of TDD - specifically, that TDD can't possibly be about guaranteeing correct results when you have 100% test coverage. Tests maybe be part of the spec, but they are not the whole thing. And testability certainly can't be a criteria for whether a feature should be implemented or not - as there will be no faster way to turn away your customer.
I am not going bad on TDD at this point, but certainly, it might come out that TDD, like Ice Cream, Chocolate, and The Force, can have a dark side we need to be real careful about.
PS - Thanks D'Arcy from Winnepeg for pointing out the broken link.