Many people interchange Test Driven Design with automated unit tests. These are two different concepts, each having potential benefits and costs. In Test Driven Design, tests essentially define requirements and are supposed to only be written when specifically identified as a requirement. No software is written until the tests are written. As new requirements are communicated, new tests are written and new code is written or refactored. Unit testing can be done with any methodology. I have worked with people who adhere to Test Driven Design religiously. While I can appreciate the approach when you are working in a completely new domain where your business knowledge is very limited, when working in an environment where you have significant experience, the process slows you down. The word refactor becomes a four letter word $#@!. Unit testing can be an invaluable tool, especially when you have classes with complex business logic. We developed a calculation engine for a leasing company that involved very complex rules and the use of automated unit tests was invaluable as the engine took on new capabilities. I have also found that the use of unit testing forced the design to clean up interfaces between various classes. As has already been said. It's a tool. First get familiar with the tool. Then use it where appropriate.