What Test Driven Won't Get Me
Thanks to Eric and Brian and other champions of test first development, I've been profitably writing unit tests and functional tests in various projects 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."