Kent Beck is credited as the TDD inventor.
Yet, he claims he just re-discovered it.
When asked why does he refers to the rediscovery (not the invention) of test-driven development he explained:
The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.
After I’d written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, “Of course. How else could you program?” Therefore I refer to my role as “rediscovering” TDD.
Mongo bonus points for anyone who can refer me to the original book
How old TDD really is?
Here’s a game: try to guess when these 2 sentences have been written.
1. A software system can best be designed if the testing is interlaced with the designing instead of being used after the design. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact with simulation models, but that in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulation model controlling, as it were, the place and order in which these things are done.
2. Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness.
But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. […]
If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.
1. Excerpt from Report of The Nato Software Engineering Conference (1968)
2. Excerpt from The Humble Programmer, Edsger W. Dijkstra (1972)
Pretty surprising, isn’t it?
It should not. The practice of “writing early unit-tests to micro-increments” wasn’t surely as widespread as today, but it was surely well known.
According to Craig Larman and Victor Basili in early 1960s IBM run a project for NASA using a technique equivalent to TDD:
Project Mercury ran with very short (half-day) iterations that were time boxed. The development team conducted a technical review of all changes, and, interestingly, applied the Extreme Programming practice of test-ﬁrst development, planning and writing tests before each micro-increment.
They also practiced top-down development with stubs.
Update: Michael Bolton found this excerpt, which comes from 1957. Wow, so far this is the oldest reference to the root of the TDD technique.
The first attack on the checkout problem may be made before coding is 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. The hand calculations can be done at any point during programming. Frequently, however, computers are operated by computing experts to prepare the problems as a service for engineers or scientists. In these cases it is highly desirable that the “customer” prepare the check case, largely because logical errors and misunderstandings between the programmer and customer may be pointed out by such procedure. If the customer is to prepare the test solution is best for him to start well in advance of actual checkout, since for any sizable problem it will take several days or weeks to and calculate the test.
Digital Computer Programming D.D. McCracken, 1957
Read the reply Michael Bolton directly received in this interview with Jerry Weinberg
Michael: […] I remember once that Joshua Kerievsky asked you about why and how you tested in the old days—and I remember you telling Josh that you were compelled to test because the equipment was so unreliable. Computers don’t break down as they used to, so what’s the motivation for unit testing and test-first programming today?
Jerry: We didn’t call those things by those names back then, but if you look at my first book (Computer Programming Fundamentals, Leeds & Weinberg, first edition 1961 —MB) and many others since, you’ll see that was always the way we thought was the only logical way to do things. I learned it from Bernie Dimsdale, who learned it from von Neumann.
When I started in computing, I had nobody to teach me programming, so I read the manuals and taught myself. I thought I was pretty good, then I ran into Bernie (in 1957), who showed me how the really smart people did things. My ego was a bit shocked at first, but then I figured out that if von Neumann did things this way, I should.
Amazing, isn’t it?
31 thoughts on “You won’t believe how old TDD is”
It’s earlier than that. Check out “Program Checkout” in Digital Computer Programming D.D. McCracken, 1957:
“The first attack on the checkout problem may be made before coding is 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. The hand calculations can be done at any point during programming. Frequently, however, computers are operated by computing experts to prepare the problems as a service for engineers or scientists. In these cases it is highly desirable that the “customer” prepare the check case, largely because logical errors and misunderstandings between the programmer and customer may be pointed out by such procedure. If the customer is to prepare the test solution is best for him to start well in advance of actual checkout, since for any sizable problem it will take several days or weeks to and calculate the test.
Wow, this is amazing!
I think people confuse the development methodology used at NASA in those days to what TDD is. And a lot of TDD/Agile people use that to justify the current ‘sliver bullet’. At Nasa there was a lot of upfront analysis to produce a spec THEN tests were written based on the spec. There was also a lot of upfront design to product a DESIGN DOCUMENT. Calling what Nasa did in those days as TDD or using it as justification for TDD now is absurd, they were 2 totally different development processes.
No one is asserting here that they were adopting agile.
Sure: they had a lot of up-front analysis, and tests were written
after specs; yet, they were written before code.
TDD is just one of the several techniques promoted by eXtreme Programming and other agile methodologies.
Anyway, I agree with you: the “early testing” technique adopted in the 50s and 60s was surely much rough that the TDD we know nowadays.
What do you exactly mean by rough? Do you mean rigid, or unrefined? There’s a substantial difference between the two…
I meant ‘unrefined’, a bit primitive, may be.
I’m interested in your opinion: would you like to comment?
Top Secret Rosies 1942, used Test first to validate artillery tables produced by computers. http://www.topsecretrosies.com
Oh you kids. Easy to imaging the following conversation: Og explains to his son that best place to spear the zebra is just below the ear on the side of the skull, but that’s a really difficult shot. The easier shot is to “aim for where the stripes part on the front of the chest” (painting the pattern on a tree trunk). “Keep practicing until you can hit that spot from 20 paces front the front or the side”. .. later.. “no hold the spear this way” .. later .. “yes, that’s better, now follow through.” .. “Now, ask uncle to teach you how to get the Zebra to come to you within only 10 paces.”
So the idea of a subject matter expert defining a target outcome and then experimenting until you find a way to achieve it isn’t new at all. 😉
Thanks a lot for sharing this with all of us you really know what you are talking about! Bookmarked. Kindly also visit my website =). We could have a link exchange agreement between us!