This post originated from an RSS feed registered with Java Buzz
by Weiqi Gao.
Original Post: What Test Driven Won't Get Me
Feed Title: Weiqi Gao's Weblog
Feed URL: http://www.weiqigao.com/blog/rss.xml
Feed Description: Sharing My Experience...
Thanks to Eric and Brian and other champions of testfirst development, I've been profitably writing unit tests and functional tests in variousprojects for more than seven years.
Nowadays I wouldn't dare delivering anything without having thoroughly tested it. For me, the tests serves three purposes:
To ensure that the functionalities are implemented correctly
To discover corner cases that you just couldn't think of during on-paper design
To provide a safety net that is needed to confidently refactor the code base to improve design
However, my own experience with the concept of test driven design has been mixed. And here are some of the limitations of the approach, as I see it:
Your test driven design won't be that much better than your non-test driven design. If you know nothing about designing a compiler, no amount of testing will make you come up with a design for a compiler
Your tests will drive you to designs that are more complicated than necessary, with an abundance of entities and interactions. You will be doing a lot of "create class", "create method", "create field" from the IDEs refactor menu, but rarely do "consolidate classes" or "consolidate methods" because no such refactoring exists
Your test driven design may drive you towards a design that's less amendable for future changes. Without forethought, you may be too focused on delivering functionality that satisfy only the current requirements, thinking "I can always refactor later to accommodate future requirements"
In other words, if you don't know how to design, no amount of testing will make you a good designer.
In other news, Donald Knuth professes that "With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me."