One of my colleagues said something at lunch today. While discussing a problem, he said “I don’t think you can reach that conclusion through TDD”. I didn’t really know what to think of that, so I didn’t say anything, for or against that statement. I just kept it on the back of my mind for a while. Full disclosure: I’m pro TDD. I think, as far as workflows go, it’s pretty good and when properly used, will add value to any code base.
Probably
TDD isn’t a silver bullet. It won’t magically make problems disappear, or turn bad code into quality code. It might help. But it also might make everything worse. You see, this uncertainty is what makes our industry so volatile. And unfortunately, there’s really no way to appease it.
Once upon a time (last December), I went to one of the Global Code Retreat gatherings in Munich. One of the exercises consisted of one developer writing the tests and another implementing them in the worst way possible. It was very easy for the person implementing them. Now, think about the opposite. Tests are all about having more confidence on how the code works and being able to change things without too worrying we might accidentally break something. Now, imagine that you can’t trust the tests on your codebase. The Horror.
There is a way for tests to actually cripple you. As with most things in tech, there’s a way to screw things up. So, yeah, TDD will probably add value to any codebase. But there’s nothing certain about it.
And that’s the thing. We live in a world filled with uncertainty. Things change so fast that whole generations are defined by wether they understand Snapchat or not. It’s 6 years old. Where before, generations were separated by wars, today they’re separated by wether or not they were still young enough to buy into the craze of a 6 year old app. Ascertaining anything other than the impossibility of assertions is quite perilous these days.
Does that mean that we shouldn’t follow TDD?
Of course not. But we shouldn’t follow it blindly. We need to understand its perils as much as we need to understand its value. Only then can we really apply it in a way that will add value. And, ironically, the best way to get this kind of knowledge is to do a lot of it.
Now, back to the original question, is there a conclusion that's unreachable through TDD? Tobias gave me a great example today, based on mathematical properties. And I agree, maybe you shouldn’t try to redefine how math works through TDD. But is that the tool’s fault, or our own for using it wrong? It’s always the latter.
Probably