Why Do You Use TDD?

After about a year and a half of writing tests before implementation, I'm not sure I will ever go back. Most people call this "Test-Driven Development." However, given the benefits that come from working this way, I prefer the term, "Test-Driven Design."

I use TDD for three reasons - (1) Test-Driven Design forces more loosely coupled code which is much more malleable, (2) I can detect code smells much faster when classes become difficult to test, and (3) it is easier to know when I'm done writing code.

The tests are a nice bonus product of designing code this way, but they are, in fact, not as important to me as the loose coupling and general good design that comes out the other end. When writing tests becomes too difficult, noisy, or lengthy, then something is wrong with the design. Since tests are in place, refactoring to a better design is easier and generally faster. So, this too aids in improving the design of the implementation.

Do the tests get in the way sometimes? Yes. However, this is often a test smell. Perhaps the tests have too much intimate knowledge of the implementation.

If you have not tried writing tests first, I suggest giving it a go on a simple project. Better yet, find someone that is already experienced in TDD and do some pair programming.

Now, go forth and write tests...