Top-down TDD/Unit-tests?
January 31st, 2004 by HenTDD is a good solid way to code, if you’re a bottom-up coder. I’m a top-down coder, so TDD is useless.
Often, I begin coding [following the sketched out design] at the top level with interfaces and a scaffold to drive the interfaces. The interfaces are all then stubbed out where implementation is necessary with a Null pattern version of some kind.
I can’t write a Unit Test here as I’m not at the unit level, and won’t be writing units until near the end of the coding session. When I reach that point, it is unlikely my framework will be suited to units and so I face the choice of either hacking the framework to make my low-level implementations into good ‘units’, or not having a low level unit test.
Effectively it’s white-box vs black-box. TDD and Unit Tests are white-box, bottom-up development. This fits a scenario in which you know exactly what you’re going to code etc etc, RUP blah blah. In a top-down scenario, you’re able to be far more creative at the code level, without having to design down to the implementation level [just the interface level], but chances are you won’t have good units.
Maybe the solution is that top-down development be used for a prototype phase, then all code thrown away and a bottom-up TDD phase is used. Prototype phase could even be called 1.0 with TDD phase 2.0.
On a positive note, I do find TDD very useful for utility style methods, where top-down and bottom-up coding are effectively the same. I also find it useful when I’m given a series of test-data as a part of a requirement.