Test-Driven Development Isn't Testing [Guest Post]

This is a guest post from Judge Maygarden:

I've tried diving in to test-driven development (TDD) a few times over the years. For some reason, it's never really stuck with me. So, I went looking for literature critical of TDD. This led me to an interesting article.

Jeff Patton makes the point that TDD is not a testing process; it's a design process [1]. Unit tests should not be written to test a function or an object. Rather, the tests should be defining some specific program functionality with objects and methods created to make that happen. So, a unit test describes the software design first, and any thorough testing is more of an afterthough.

That makes the leftover regression test part of TDD a little less appealing. However, Patton makes a very good case for TDD by replacing "testing" with "design" as follows:

Looking back at the three common reasons for not writing unit tests, let's substitute design for test:
• Designing takes too much time.
• How could I design first if I don't know what it does yet?
• Designing won't catch all the bugs

That makes TDD sound like a no-brainer. In my opinion, it really seems to boil down to using the best tool for the job. If your development environment is geared towards the TDD design process and profligate refactoring, then go for it. It does seem like a productive design process. Just don't forget to test it with other techniques as well.

[1] Patton, Jeff (2005). Test-Driven Development Isn't Testing. In StickyMinds.com Software Testing & QA Online Community. Retrieved from http://www.stickyminds.com/s.asp?F=S8497_COL_2.

Show Comments