Wednesday, January 23, 2008

Is TDD useful?

I have heard a lot about testing lately. First I was told you need tests. I don't disagree with that at all. Companies wouldn't devote entire departments to testing if doing it was trivial or useless. Automated testing is ideal since you don't have to hire an entire department for this task but this can be difficult and hints at the heart of this post.

Then I was told that behavior driven development (BDD) was important. That you would create automated test cases that try to stress the way certain behaviors of the system should act. This has always seemed very nebulous to me and so close to test driven development that there really isn't a big difference between the two.

Which gets me to test driven development, TDD. The whole idea about this is that the developer really thinks about the method/function/module he/she need and writes tests first that express what that method should do. Supposedly this creates stronger and more robust code. Some developers have really hammered this thought into the agile development world about how testing first WILL create better code and more productive programmers.

Then I read this article. Basically, it says that testing does help but the number seem to show that testing a method after it is written actually creates better code. It says that tests are still really useful but writing tests first don't actually create better code and may actually be worse than testing methods after the fact.

What does this say to you about my development practices? Well, I will continue to write automated tests but the jury is still out on TDD. And, personally, I don't see any compelling reason to change my, or my teams, current development practices based off of some shaky numbers. Especially if it's true that testing after a method is written is better. Change isn't always for the better.

No comments: