Test Driven Design, offers significant advantages over Top Down Design, but is a practice that requires a high level of skill. In essence it prevents the need to write the program twice, and provides testing as an integrated part of the product rather that an afterthought
The question has always been when should design stop and coding start? Some advocate of the Top down approach go as far as suggesting that methods should be described in pseudo code or OCL prior to development(Bennett et al., 2006, p. 301) Test Driven Design eliminate this and requires code to validate the design described by there already in place tests. Effectively effort is diverted away from design, to quality.
Test Driven Design, refers to design, “the how”, it does not relieve the development team of the analysis, “the what” , by the time we are in a position of developing tests , we need to have established what it is we are trying to do. Proponents of agile method, often fail to describe this explicitly but the analysis activities do take place but in an iterative manner and often in conjunction with UML; “A common use of diagrams is to explore a design before you start coding it. Often you get the impression that such activity is illegal in XP, but that’s not true.” (Fowler, 2004) large applications require significant level of analysis to decompose, the application into components of a manageable size. From there on agile practices can take place independently.
The requirement for a high level of skill results from the fact in that design results directly from the coded developed rather than as a separate product created by a highly skilled professional / team and handed over to regular developers. It is for this reason the extreme programming advocates the uses of pairs programming. It is eventual that developers are aware of design principals, patterns etc, and do not just codes against and API. Within my organization although the development process maturity had not yes reached a level that I could add Test Drivel Design, We do practice test driven development, One practice I actively participate in with my teams, is to reverse engineer code using UML tools and then review the generated diagrams prior to “refactoring” or should I say redesigning. This enables a visual check of the design, and with modern tooling is a very fast process.
Whilst Test Driven Design has slowly been gaining ground in undergraduate and graduate academic circles, it has been rapidly gain ground in school classrooms. (Janzen & Saiedian, 2005) With it incorporation into products such as BlueJ, and education java IDE, it is very likely that the next generation of developers will consider Test Driven Design as a normal practice.
Perhaps the most compelling of arguments for Test Driven Design, and Test Driven Development come from IBM: “With TDD, unit testing actually happens.
In our prior approaches, testing was an afterthought.”(Maximilien & Williams, 2003) The IBM Team, inexperienced with the method, achieved a 40% reduction in the defect density on the first trial project.(Williams et al., 2003)
Both Test Driven Design, and Test Driven Development offer the opportunity for significant improvements is software quality. Test Driven Design require significant level of skill within the development team compare to other design techniques, but funds its extra effort by replacing formal design. Activities such as pairs programming mean that this skill can de developed. TDD is the start of a new bread of responsible programmers.
Bennett, S., McRobb, S. & Farmer, R. (2006) Object Oriented Systems Analysis and Design Using UML. 3rd ed. Maidenhead: McGraw Hill.
Fowler, M. (2004) Is design dead? [Online]. Available from: http://www.cs.unm.edu/~rstehwien/CS580/reading/Is%20Design%20Dead.pdf (Accessed: 27-5-2007).
Janzen, D. & Saiedian, H. (2005) ‘Test-driven development concepts, taxonomy, and future direction’, IEEE, pp.43-50, [Online]. (Accessed: 21-6-2009).Doi 10.1109/MC.2005.314
Maximilien, E.M. & Williams, L. (2003) ‘Assessing test-driven development at IBM’, IEEE Computer Society, [Online]. (Accessed: 21-6-2009).Doi ISBN ~ ISSN:0270-5257 , 0-7695-1877-X
Williams, L., Maximilien, E.M. & Vouk, M. (2003) ‘Test-driven development as a defect-reduction practice’, IEEE, pp.34-45, [Online]. (Accessed: 21-6-2009).Doi 10.1109/ISSRE.2003.1251029
TDD certainly has some significant benefits for higher-level software development; however, as an embedded software engineer I’m concerned that this doesn’t map completely to the products we develop. Once you have hardware, firmware and low-level software then TDD makes perfect sense – prior to that…?
At work we’re moving over to this way of thinking, which is causing some upset for some of the more traditional programmers; the idea of designing code to pass a test rather than trying to bolt in every imaginable piece of functionality is proving alien to some (or maybe it’s the just the requirement to have test harnesses that aren’t treated as optional overhead!).
Relatively recently a number of our engineers attended a sw testing course where one of the exercises was a pure TDD – slightly artificial, but building a queue where each stage *only* provided the functionality needed to pass the test (with no implicit additional functionality) proved to be almost distressing for some.
It should make for interesting times…