DHH had a post about TDD which apparently has raised a lot of comments. The usual suspects have replied, showing once again they don’t get it (and in this case adding one of the dumber discussions of monogamy I’ve seen in a while….then again, he’s a developer sort, so, you can’t really expect much).
DHH says:
But first of all take a deep breath. We're herding some sacred cows to the slaughter right now. That's painful and bloody. TDD has been so successful that it's interwoven in a lot of programmer identities. TDD is not just what they do, it's who they are. We have some serious deprogramming ahead of us as a community to get out from under that, and it's going to take some time.
I certainly agree that TDD is a sacred cow for some, and a part of some programmer identities, but I most certainly do not agree that it has been “so successful”, going so far as to posit that it hasn’t been successful at all, from almost any perspective. The vast majority of test suites that I have encountered have been inadequate, unmaintained, meager, or even worse, have created horribly conceived code bases that are based on myopic opinions about testability, as opposed to what makes for well conceived code or properly driven software development.
Uncle Bob’s response is enlightening in ways he certainly didn’t intend, but I want to focus on one thing he says in particular, what he apparently thinks is the most important thing:
If you have a test suite that you trust so much that you are willing to deploy the system based solely on those tests passing; and if that test suite can be executed in seconds, or minutes, then you can quickly and easily clean the code without fear.
Think about this for a minute.
Cleaning code doesn’t even make it into the top five on the list of most important developer practices, and most definitely not even in the top twenty of most important software development practices.
He talks about how clean code allows developers to code quickly, and without fear. Simply for the sake of argument, I will accept this for the moment.
But being able to quickly code poorly conceived code is not a good thing. Most importantly, it’s the wrong focus.
Let me repeat for emphasis, it is the wrong focus.
The proper focus involves determining the proper business requirements and executing them.
Testing itself, properly conceived, is within the top five of most important developer practices, and at least cracks the top ten of most important software development practices.
But TDD, paradoxically, typically (though not always) leads not only to bad code development, but bad testing itself.
To be a good developer, one really needs to stop thinking and being just a developer, and learning the techniques of TDD but abandoning the dogma of it is probably a necessary step in that direction.