Today, I’d like to talk about Test-Driven Development (TDD) and its place in our developer life. Especially, since it is a software practice that has received a lot of attention recently, especially in the Agile World.
I’ve had many discussions with my colleagues about TDD. Don’t get me wrong, I like the intention behind TDD but I just can’t convince myself that we should always use TDD, everywhere. Of course, using words like “always” and “everywhere” makes it easy not to be convinced of anything! There are always exceptions and I’m sure my colleagues would agree with that, so in a way, we’re on the same page ;)
What makes me skeptical is how a small group of individuals, with evangelistic motivation (lecturers, consultants and the likes), are now taking a lot of place in the prevailing discourse, having found THE way (or should I say “the silver bullet”) to develop every kind of software. The TDD practice is very appealing (or not), in a way, because the principles behind it are so simple. More people are quickly adopting the practice, as if it was bad not to adopt it. But wait a minute… Why should someone change his software practice if it’s working for them, for their context, etc ? In fact, many people don’t because they don’t feel they need to and I think they might be right.
Read recently on a forum post answering the question “What do I lose by adopting test driven design?. This post was supposedly written by Uncle Bob (Robert C. Martin), writer of several good books on software design, lecturer and a very active proponent of TDD.
You lose the ability to say you are "done" before testing all your code.
You lose the capability to write hundreds or thousands of lines of code before running it.
You lose the opportunity to learn through debugging.
You lose the flexibility to ship code that you aren't sure of.
You lose the freedom to tightly couple your modules.
You lose option to skip writing low level design documentation.
You lose the stability that comes with code that everyone is afraid to change.
You lose the title of "hacker".
Ok, on the surface, it is funny but the content is debatable. First, the way he writes is misleading, because he is suggesting that he knows (or implies) what software practice the reader uses. What about people carefully writing their tests last and carefully designing first? What about people writings tests first without doing TDD ? What about designing by contract ? Why is Uncle Bob implying that if I’m not doing TDD then I must not be testing my code or I must be designing it badly ? Was all software badly written before TDD ? Of course not ! But it seems to me that this kind of discourse is way too common these days. I really like Uncle Bob, he is very charismatic . Unfortunately, the way he talks, the way he writes, when he sells TDD and professionalism, is demagogic . I’ve heard him debate with Jim Coplien, a well-known writer, lecturer and researcher, and he is a lot less demagogic when he is challenged. I cannot prove the following assertion but it looks to me like he decided to stop the interview when he concluded that he could not convince Jim Coplien. I’d like to add that Uncle Bob did not convince me that a good architecture would emerge efficiently, using TDD, when responding to Coplien’s example of programming a bank account.
Now back to TDD. I’m not saying TDD is bad, all the contrary. But the burden of proof is on the side of the proponents of TDD. There is not enough empirical studies on the matter to conclude anything yet. The studies I have read conclude often to mitigated results because it is very difficult to isolate the factors influencing the metrics. For me, it is very clear that convincing people to adopt TDD by showing coding kata demonstrations and a persuasive argumentation is not enough. Sure, it will influence people. But we should ask for numbers ! Show me the numbers! And I don’t care if Kent Beck successfully applied TDD to every projects. Kent Beck is hardly representative of the common programmer.
Moreover, I claim a more global approach in choosing our software practices. Certainly, I agree that there is a general need for improvement of the software quality delivered in the industry. Certainly there is still a need for more professionalism. TDD might have served its purpose in bringing testing software quality at the center of the discussion. TDD also served its purpose in bringing software design on the front line. But now that we are more conscious about that, could we consider choosing other alternatives? There are many ways to achieve quality software. And what is quality software anyways…
I’d like to conclude on the following note; my latest thoughts and readings on the subject got me deeply interested to know more about Design by Contract programming, which seems to me like a more formal approach to testing software than TDD is.
Bye !
