TDD, BDD, or NDD

Test-Driven Development, Behavior-Driven Development, and No-Driven Development. That’s right, there are only three options. And if you’re a NDD kind of coder, you may as well stop programming altogether. You must be a terrible programmer and a terrible person. How dare you.

Enough with the sarcasm.

But that’s what some people would have you believe. It’s the same as the Python developer saying Ruby sucks. We all know Ruby doesn’t suck, it’s just one point-of-view from a person who chooses to use Python. They’re both very viable alternatives that can solve much of the same problems.

I don’t like TDD for the sake of good test coverage. There are plenty of tools and other ways to ensure that you have good test coverage. You could write the entire application before writing any tests, and still come out with solid test coverage.

The reason I like TDD is because of its inherent nature to assist with problem solving. Like any good programmer, it’s important to understand the problem you’re trying to solve before you start solving it. And what better way to do that than to break it down and list what it should do. You could do this on paper, or you could do this in a test document. I happen to choose to do this in a test document, but that doesn’t make me any better of a developer than you. After all, it’s still me breaking down and solving the problem. You might be better at that than I am.

The truth of the matter is, these tools and processes exist to improve upon the code quality and development of libraries and applications. It’s important to at least keep an open mind and accept the fact that there may be a better way. Try it, if it doesn’t work, no harm done.

The end.