A History of Test-Driven Development (TDD), as Told in Quotes
Nope, I haven’t forgotten that my next newsletter was going to be in response to a comment on the last newsletter. But I’ve discovered the need for some diagrams, or code, or something other than prose, to explain myself succinctly. So, it’s taking longer than expected.
A lot longer.
So, instead, I give you a “lost” (axed) chapter intro from my upcoming book, Essential Test-Driven Development (Addison-Wesley, out early 2021 if I’m sufficiently industrious). I hope you enjoy it.
A good way to track the progress of the book is on GoodReads.
Happy Holidays!
A History of Test-Driven Development, as Told in Quotes
“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.”
—Kent Beck, re-discoverer and namer of Test-Driven Development
“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. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.”
—The Humble Programmer, Edsger W. Dijkstra (1972)
“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.”
–Excerpt from Report of The Nato Software Engineering Conference (1968)
“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 calculate the test.”
—Digital Computer Programming, D.D. McCracken, 1957
Hold on now, Dijkstra meant something _very_ different from TDD. In TDD we work by induction over examples, Dijkstra, on his very strange mission to make programming almost impossibly difficult, wanted programs to arise from proofs of the kind that mathematicians publish: deduction from axioms and lemmas.
I say “publish” because mathematicians actually find theorems by induction over examples, but they then create deductive proofs for publication.
You are very right! I was mostly intrigued by the notion that the proof would be growing alongside the code. It’s that notion that there’s some form of “flip-side” to the software coin that can’t be done all up-front, and isn’t as valuable if done afterwards.
I often point out that TDD as we do it today would have been impractical in the 80’s for example. I recall one moderately-sized Ada module taking a half hour to compile on a microVAX. Write a test, wait a half hour. Write some implementation, wait a half hour…
So a lot of these quotes will not reflect what we do today. But TDD is so much more than the mechanics of red-green-clean. I like the way you’ve phrased it as induction over examples.
I think of it as a simple discipline we use to craft our code. We do this by creating a refined engineering specification, which leaves behind a safety net protecting our investment during further refinement and enhancement. The discipline builds upon itself, and the benefits grow proportionally to the duration. The most long-lived, most resilient, most frequently changing, and most defect free product I’ve ever been involved in was written test-driven, 18 years ago. It’s still in operation, and still undergoing occasional enhancements as its domain of biological science changes.
Yes, the technical constraints have changed. Larman quotes Weinberg in claiming that early NASA programmes (Mercury, I think) used an XP-like process with technical practices much like TDD. But that was a programme to address a perceived existential threat, with almost no cost constraints.
I too recall the days when for the jobbing programmer in the industry at large an incremental build took long enough for a leisurely tea break, and you started a full build on Friday afternoon before going down the pub and you hoped it was fine by the time you came in late on Monday. TDD would be little help in such a world.
Does anyone know on which site the qoute from D.D. McCracken is from?