Test Driven Development (TDD) is a technique used for software design where development begins with testing and the design of the code emerges. First a developer defines a method necessary to solve a business problem. Then a unit test is created to test a method implementation. Finally, a method is created in a class until the test passes.
The application continues to emerge as each new test is created, and code is implemented solving each test. Advocates of this technique assert that there is no architectural decision made, and that the architecture emerges as a result of writing +-and solving each individual test.
I am not so sure that is truly the case. How did the developer know what test to write first, and in what class to create the method? If you were sitting down to create an UML class diagram is it really any different than sitting down and writing tests? Of course, it would be faster to create a diagram than writing tests…but the net effect is the same.
So I’m thinking that the net effect of TDD is to create a design much as you would with UML. The difference is, once you complete a TDD implementation you have working code instead of a diagram. Granted, you might change your classes through the development process just as you might change a diagram, and the changes may require refactoring of your classes. In my experience, the short amount of time to re-factor tests and code is usually quite short; and the validation of your code through tests has higher value than diagrams.
What do you think? Does TDD exclude design, or is it an implementation of design? Does the design really emerge, or has a design already been started and the tests simply validate the design? Leave your thoughts here online or drop an email to btaylor@sswug.org.
Cheers,
Ben