I read an article this morning on Test-Driven Development, or TDD. TDD is the software development paradigm that dictates that you don’t write any code without first writing tests for that code; that way, you’ll know when you’re done (all the tests pass).

Without getting into the pros or cons of TDD, my main problem with this article is the holier-than-thou attitude its authors take. This is all to common in discussions regarding TDD: “if you’re finding it hard to follow TDD, it’s because you’re not a capable enough programmer.” Or, “if you’re finding writing tests is taking too long compared to simply debugging problems, then you’re doing it wrong.”

Both of these statements may be true, but certainly aren’t always. There are legitimate criticisms to TDD. I won’t list them because I don’t want Hacker News commenters to start nitpicking. I hate nitpicking. The problem is really that whenever someone brings up a problem with TDD, they’re shot down with religious vigour and told the problem isn’t TDD, the problem is them.

Well, fuck that.

Maybe TDD doesn’t work for every developer on every project written with every language using every framework.

The fact that I can only say this is maybe true without invoking the wrath of TDD Believers is a testament to how unthinkingly some developers push TDD.

To me, the main benefit to TDD was never actually the tests - the tests are meaningless! The main point to TDD is stopping. Thinking. Planning.

Before coding.

TDD may work well for you and your team on your project. It may, however, not. And there’s nothing wrong with that.