What is the origin of TDD?

Question

I have seen people point me to many different "origins" of TDD. Some will point me to Kent Beck's rediscovery in the late 1990s with XP. Others will mention the 1960s best practice of annotating the results on the sides of the punch cards to check things faster and more accurately. And, still, some will point me to various books on software reliability dating from the 1960s to the 1990s.

But is there a seminal paper or book with a formalization of the process dating from before Kent Beck's XP Explained book? Could someone who has thoroughly studied the topic create a timeline?

Answer 1

The term of test driven development is borrowed from XP which leads us directly to Kent Beck. Browsing through specialised literature shows that the terms of TDD, test driven design, test first programming and similar terms only emerge after Beck's book.

TDD is very different from annotations on a punch card or software reliability and quality practices dating back to before the 1990s. Software quality pioneers argued already a long time ago for early and systematic tests. But these quality oriented approaches are at best parallel to the development. They are conducted to prevent bugs, verify and validate software. In "The growth of software testing", D. Gelperin, & B. Hetzel explain in 1988, based on a very broad analysis of existing methods:

The life cycle models move the focus of testing from the end of a project to its beginning. This shift results in the view that testing is not a sequential phase affecting just the software implementation, but is on a parallel track affecting software requirements and designs as well. Testing is seen as strongly interacting with development activities from the very beginning of a project.

This does not mean that test can not contribute to the improvement of the software design, as IBM's "Guide to Testing in a Complex System Environment" points out in 1974:

The test planning must begin early in the develop- ment cycle (...). Testers look at the specifications from an entirely different point of view than do the developers. As such, they can frequently spot flaws in the logic of the design, or the incompleteness of the specification. In doing this, they help the developers to produce a superior product, and accelerate the actual program development.”

But interacting with design and implementation and spotting flaws is not driving the development. So we were still far from TDD. In TDD the writing of the test contributes to the design.

Nevertheless Beck was not the only one with this idea in mind. In 1992 for example, a paper about "Object Oriented Simulation of the CSMA protocol" by H.Saiedian suggest that tests should precede the design and bulding of complex systems. The author did not invent TDD, since his article is about simulation of telecom systems. But the emergence of TDD principles are clearly on page 5:

(...) This feature of object-orientation allows one to consider experimenting with a simple implementation consisting of important objects as well as objects that serve as "stub" or "driver" (or in general,"placeholder") which can aid in the definition, formulation, and testing of object interfaces and interactions; subsequent modifications can be made to the model to develop a more detailed implementation of some or all of the objects on a controlled, gradual basis.

IMHO, I think that the emergence of object orientation, and iterative development approaches, stimulated this kind of thinking. It is not excluded that other teams used TDD like approach without ever having published it. So Zeitgeist or not, Beck is still the first who made a mature concept out of it.