Origin of TDD

There is literally no written evidence as to when the practice of TDD was introduced into computer programming or by which company it was first used. Nevertheless, there is an excerpt from Digital Computer Programming, by D.D. McCracken, in 1957, which indicated that the concept of TDD was not new and had been used by earlier folks, though the nomenclature apparently was different.

The first attack on the checkout problem may be made before coding has begun. In order to fully ascertain the accuracy of the answers, it is necessary to have a hand-calculated check case with which to compare the answers which will later be calculated by the machine. This means that stored program machines are never used for a true one-shot problem. There must always be an element of iteration to make it pay.

Also, in the early 1960s, folks at IBM ran a project (Project Mecury) for NASA where they utilized a technique like TDD where half-day iterations were done and the development team performed a review of the changes made. This was a manual process and cannot be compared to the automated tests we have today.

TDD was originally popularized by Kent Beck. He attributed it to an excerpt he read in an ancient book where TDD was described with the simple statements, you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. The concept of TDD was redefined by Kent Beck when he developed the first xUnit test framework at Smalltalk.

It is safe to say that the Smalltalk community used TDD long before it became widespread because SUnit was used in the community. Not until SUnit was ported to JUnit by Kent Beck and other enthusiasts was it that TDD became widely known. Since then different testing frameworks have been developed. A popular tool is the xUnit, with ports available for a large number of programming languages.