Misconceptions with Test Driven Development

In the past few weeks I’ve heard several misconceptions raised about Test Driven Development:

• Does TDD really work? George Dinwiddie maintains a list of case studies (including one from IBM). Finally Keith Braithwaite has recently done some research on measuring the benefit of TDD. Currently the results are buried in a presentation (pdf). Key message: “measuring a over 20 projects: if you have a large number of unit tests your code will be an order of magnitude less complex.”
• Writing the tests after the code has been written is the same as Test Driven Development. Its not, there are significant benefits to TDD that I outlined in: “Test Driven Development vs Plain Old Unit Testing”.
• TDD isn’t useful for helping to design the architecture of programs.

The later is an interesting question. You can find voices on the net that say TDD by itself (with no thought given to the architecture is bad). The best example of this is “Coplien and Martin Debate TDD, CDD and Professionalism” (with some excellent comments) and a few blog posts that follow: “The TDD Controversy - JAOO 2007 ” and “TDD vs good design/architecture principles” - outline the debate.

If we accept that TDD isn’t entirely sufficient for design, then the question becomes how much architecture is required and what would a good project designed with TDD look like?

The real trick is balancing upfront design with the principle of YAGNI. Since like most developers I’m tempted to over design (“I know I will need this method/class later on”), I force myself to wait until the last responsible moment (typically just before I would need the code) to do my design work (saving a lot of waste - in the form of unused code). In the case of the larger architecture I discourage people from thinking more than one iteration ahead, any further ahead and the requirements are likely change. On rare occasions this means missing a big issue that forces a lot of rework. Since I have a rock solid tests I’m not all that upset and I believe I’ve still saved a lot of time with the architecture I didn’t build.

So if TDD can be used on a large scale and to help drive architecture there must be examples. The leading members of the community (JB Rainsberger, Nat Pryce and Lasse Koskela) all have clients with products built and architected using TDD. Unfortunately these are all closed source or clients that don’t want to be talked about publicly.

In the open source world there are a number of applications and libraries developed using TDD:

• Obviously all of the Agile related tools (JUnit, NUnit, MbUnit, Gallio, JMock, RMock, CruiseControl, CruiseControl.NET and Hudson) were developed using TDD. However this is just a bit self referential
• Bazaar - a distributed version control system, used by: LaunchPad, MySQL and Mailman (Python)
• Allelogram - a program for normalizing and binning microsatellite genotypes. (Java)
• Jena - a framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine. (Java) Related: Eyeball - lint for RDF/OWL
• Helium - (He) is a lightweight and extremely useful templating engine based entirely on XML. He is 100% Java and 100% TDD (Test Driven Development) (Java)
• http.net - a dirt simple HTTP server written in C#. It supports minimal functionality and is primarily intended as example code for TDD et al. (C#)
• Joda - provides a quality replacement for the Java date and time classes. (Java)
• Joyent Connector (source) - The Connector suite of applications provide cool features such as search, tagging, and RSS feeds that we believe will make your life easier on a day to day basis. (ruby)
• Task Coach - a task manager written in Python.
• In addition the Google Chrome browser was developed in part with TDD: Chromium has used a combination of test-driven and other development processes. Sometimes we write tests first and then implement features to pass them, sometimes we use existing tests as a guide to what to work on next, and sometimes we implement first and test afterward. It depends on the subject at hand, and on the individual developer.
• Mark Shuttleworth remarks TDD is used in developing Ubuntu.

Undoubtedly there are a number of open source projects that are Test Driven, please let me know if you’re aware of some I missed. In addition to proving its possible these projects also act as examples as to the sort of architecture that TDD can help build.

Image via: https://photodune.net/