Test Driven Development is one of the original principles of eXtreme Programming and like most of the XP principles it serves multiple functions and is interwoven with all the other practices. All by itself, however, it can provide significant benefits for your development cycle including increased quality and, arguably, increased productivity. In addition it is one of the easiest practices to explain and to actually implement.

Yet is one of the harder practices to adopt. Individual developers resist because it means additional programming not related to solving the actual problem. Management resists because they believe the additional programming means lost productivity.

The name is a little misleading because there are also design benefits to programming your tests first. The agile community even stresses those benefits over testing. But even the design benefits aren't enough to convince people.

Let me present a technique that can be adopted quickly, doesn't require much change in the way developers currently work, and requires almost no time to get up to speed.

On almost every project I've ever worked on, I've generated tons of debugging files. Either I'm examining program logs, inserting debugging statements which write to the console or a file or I've written scaffolding to generate results which I then check by hand.

Here's the idea. Once I've checked the results, the output becomes the reference standard. All I have to do is copy that to a compare folder and compare the results from future runs. I can automate that process with scripts and a diff program. I can even report pass or fail depending on whether the files compare or not.

As I've described it, this is really Test After Development, which loses some of the design benefits of writing the tests beforehand. It is better than not writing tests at all, and, with one small change we can turn it into Test Driven Development.

The one change is to create the reference file before the code is written. It is fairly easy to program output statements to match a given file as long as the format isn't too challenging (pagination isn't important and neither is lining up columns, for instance).

Some modules are easy to create tests for. To test a square root routine, all we have to do is multiply the result by itself and compare to the input. This test is easier to do programmatically.

Some modules are more difficult. If you are testing a program that produces web pages, you could specify the html in your test program, but then you have to escape all the quotes and other tricky characters as well as write comparison routines. Once you are finished with all that, they will change the html page and you have to go through it all again. It is much easier to mock up the page in a file (and make sure it is correct with a browser and validator), and then compare the mock up to the output of your program.

I have been using this methodology on my personal projects for the past few years and it works. Unless the project is major (more than a projected week of effort), I usually start with the program and only tack on the tests afterwards, but that quickly changes to writing the tests first.

My personal experience agrees with the studies. I am more productive because I find out about bugs earlier, because the process of creating the test file gives me insight into the way the program or module should work, and because I am more willing to refactor code when necessary since the tests assure me of the results.

References:

(1) Erdogmus, Hakan; Morisio, Torchiano. "On the Effectiveness of Test-first Approach to Programming". Proceedings of the IEEE Transactions on Software Engineering, 31(1). January 2005. (NRC 47445). http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html. Retrieved on 2008-01-14. "We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive."

(2) Müller, Matthias M.; Padberg, Frank. "About the Return on Investment of Test-Driven Development" (PDF). Universität Karlsruhe, Germany. 6. http://www.ipd.uka.de/mitarbeiter/muellerm/publications/edser03.pdf. Retrieved on 2007-11-01.

(3) Nachiappan Nagappan & E. Michael Maximilien & Thirumalesh Bhat & Laurie Williams, "Realizing quality improvement through test driven development: results and experiences of four industrial teams" Published online: 27 February 2008 Springer Science + Business Media, LLC 2008 http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

(4) Thirumalesh Bhat; Nachiappan Nagappan; "Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies"

(5) http://www.infoq.com/news/2009/03/TDD-Improves-Quality

(6) E. Michael Maximilien; Laurie Williams; "Assessing Test-Driven Development at IBM" http://collaboration.csc.ncsu.edu/laurie/Papers/MAXIMILIEN_WILLIAMS.PDF; 50% reduction in defects

(7) Pekka Abrahamsson; Juho Jäälinoja; IMPROVING BUSINESS AGILITY THROUGH TECHNICAL SOLUTIONS: A Case Study on Test-Driven Development in Mobile Software Development

(8) Deborah Hartmann; Interview with Hakan Erdogmus; http://www.infoq.com/interviews/TDD-Hakan-Erdogmus