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.
