Time for TDD

Test Driven Development (TDD) is gaining more acceptance in programming circles. But at least one question still remains. When should you apply TDD? In other words, when do you develop the tests? A simple answer is to create the tests first. That way you have tested code from day one. However this may not always be the right way to go.

I read a blog entry stressing that TDD is beneficial for maintenance work. You should have mature code complete with self tests. However the very first class you write for a new system may not need tests right away. Testing may in fact get in the way of rapid progress. I myself am divided on this very topic.

In a perfect world, you would have understood all the requirements and performed a full analysis and design on the project. At that point you are ready to add TDD before you write the first line of code. The real world is never perfect. So this may not be the way to go. Sometimes you need to write some code to figure things out. I would not call this production code. This may be throw away code. And that code does not need TDD applied to it.

We do not use TDD in general on my project. I have tried it. For small tasks it seems to work well. But when everything is crazy and we are terribly behind schedule, the TDD goes out the window and we hack together solutions. Sure it is not the best way to go. But it is life. There is probably a time and place for TDD. That time may not be before you write any code.

Cost of TDD

I read a blog about a developer that tried Test Driven Development (TDD) for a day. He found that a useful way to generate the tests is to debug your code. When you find errors, you can write a test that checks for that bug. This would be perfect for my project. It is a maintenance project. We get trouble tickets all the tine that we resolve. It would not take much more effort to integrate the tests for the bugs we fix into a automated test script. We already do the unit testing for each fix anyway.

Getting back to the subject of TDD, the developer who tried it and wrote about it did not like it. He said the TDD technique led to very little actual debugging. He did gain some new respect for the method in general. However he would still not use it for everyday programming purposes. While the effort did seem to result in higher quality code, it took much longer to develop code that way.

When can you use TDD? I know we can’t use it on our project. We hardly have the time to race through coding and hack together some solutions on my project. If TDD causes the development cycle to double in time, we would never get anything done at my job. Here is the funny thing about this.

Perhaps we really are the best candidates for a TDD approach. The problem is that it would be a hard sell. One of the main things that drives our schedule is customer needs. And our particular customer wants more functionality in less time. They don’t seem to care about our methodology. Yes they do not like bugs. However they will tolerate bugs if it means they get a lot of features right away.

Production Volume

I read this blog about how you should test using volume comparable to production. Big hard disks cost little these days right? Wrong. Well yes some el cheapo hard disk can be found for a bargain. However that disk will never match the characteristics of our production server box.

Now I don't know all the details. But we have a massive box to run our production system. There is probably something like 128 processors on the darn thing. And there is more RAM in there than you could find on a mainframe.

Don't get me started about the super speed disk array we got powering our database. But I guess you get the point. You cannot compare your little bitty workstation with a production box. To do some is futile. I guess the only pearl of wisdom from the blog post I read was that you should not do tests if you only have a couple records in your tests tables. Point taken.