On Test-Driven Development (TDD)

Let me get one thing out of the way first: I am open to Test-Driven Development (TDD). I am not currently practicing it, because when I gave it a try some time ago it did not seem to work for me, but I do not have any objections to it in principle, so I might give it another try in the future. Let us just say that it was not love at first sight, but then again some relationships do take some time to warm up.

Having said that, let me now express a few reasons why I am skeptical of TDD. The previous paragraph should have established that I am not trashing TDD, I am just expressing some reservations.

(Useful pre-reading: About these papers)

Reasons why I am skeptical of TDD:

• The religion effect

Advocates of TDD say that it is the only proper way of developing software, and any other way is just plain wrong. If you do not like TDD, it is because you do not understand TDD. If you don't practice TDD, you are being unprofessional. In other words, TDD seems to have gained religion status. Its disciples are saying that their way is the one true virtuous way, and if you are not following it then you should repent and change your evil ways. As a civilization we have been there, done that, it did not work well.

• The Life of Brian effect

In Thoughtworks - TW Hangouts: Is TDD dead? (youtube) Kent Beck (the inventor of TDD) says starting at 13'19'' that there exist problems which are not amenable to solving via TDD, and when he comes across such problems, he does not use TDD. Martin Fowler adds that for him, the most important thing is to deliver properly tested code, and whether you write the tests before the production code or the other way around is secondary, and a matter of personal preference. Note how these statements constitute blasphemy among hard-core practitioners of TDD. It appears that the original prophets do not endorse the creed as fervently as the adherents.

• The stealth effect

Obviously you must never commit failing tests; this means that others should never be able to tell, by looking at the commit history, whether you wrote the tests first or the production code first. This in turn means that TDD is not observable, and therefore not enforceable, so perhaps we should not be too worried about something which is, by its nature, each developer's private business.

• The envy effect 

Even though Test-Driven Development is a way of developing software which is based on a special way of doing testing, people seem to feel compelled to use the TDD buzzword with every opportunity, so the term is quite often used as nothing but a synonym for just plain testing. I come across articles which mention TDD in the title, but when you read the text you discover that absolutely nothing in there applies to writing the tests before the production code; therefore, the article was not about TDD, it was about testing at large. This in turn is an indication that TDD is being mentioned far more often than it is actually being practiced.

Are these observations damning about TDD? No; I am just saying.