What? You’re doing TDD!

I’ve always been distrustful by default with the “main way of thinking”. Which doesn’t mean that I systematically reject the opinion of the majority. But given the strong tendency of human beings towards laziness and our natural tendency to sheep-like behaviour, the faster something gets popular, the more I question it.
Test-driven development has always fallen in this category for me. The problem it’s supposed to solve is real: software coding is a highly error-prone activity and we need to do everything we can to avoid shipping erroneous code. I totally agree with that. But then TDD is just one solution to this problem: to avoid shipping errors, let’s test and check our code in order to detect errors before shipping. But this solution leads to other problems:

• tests are just more code where there can be other errors, and that need to be maintained. So what about false positives and negatives?
• test writing has always looked like a very boring and chore-like activity to me, especially if it involves thinking about my implementation algorithm before I actually write the corresponding algorithm, which is often required when doing behavioral testing
• I’m still not convinced that ensuring each part of the system is working is supposed to reassure me about the system as a whole.

And more importantly, there are other alternative solutions to the same original problems: for example, instead of waiting for tests to fail to fix mistakes, why not trying to avoid them in the first place? We have some pretty good tools for that: refactoring is error-prone, especially when you use a refactoring engine that is not reliable. Then stop using Eclipse, move to IntelliJ. You keep reproducing the same wrong patterns from some old language you’ve worked with for 10 years? How about static analysis? And instead of typing that much error-prone boilerplate code, why not use code generators or dynamic languages like Groovy? I’ve been using all of these tools for years, and I’m gonna say something bold here: I shipped some pretty decent software with not enough bugs to justify the  weight of TDD. A craftsman can also go a long way in improving his work by getting better tools, and training himself to use them. Actually that’s what really pisses me off with all the TDD religion thing: too much focus on techniques and processes, not enough on technologies and people. And I think I’m just more interested in the latter two.

Now most of the time, when I raise my objections about TDD to people who say “What? You’re not doing TDD!!!” with some sort of horrified look, they just answer me with disdain instead of actual arguments, which can mean one of 2 things:

1. They didn’t look into it that much. They just followed the trend because it seems nice to say that you do TDD
2. I didn’t look into it enough and some of them are actually right to treat me that way, because I don’t know what I’m talking about

I thought I had tried TDD enough in the past to avoid the second option, but this morning I attended an amazing talk by Robert C. Martin at Devoxx. In fact, there was another talk before by Ivar Jacobson. And the guy kept talking about software as an industry (comparable to manufacturing for example), about the fact that we have a big professionalism issue (which I totally agree with), and that in his view the best way to fix the problem is to add some theoretical foundations into the mix. Let’s say I didn’t agree at all with his view of where the problem lies, and with his inferiority mix up towards other industries. But on the other hand, I agreed a lot with Uncle Bob’s view of things… until he started talking about how silly it was not to do TDD these days. How can I agree with his conception of where the problem really is, and not with one of the main solutions he proposes. Maybe I’m missing something here. The best way to figure it out is to read in more details what he has to say. And given the incredible energy he showed in his talk this morning, his book is likely to be a lot more interesting than all the TDD manifestoes I’ve read in the past (or tried to read before falling asleep).