Are Test-Driven Development and Literate Programming the Same Discipline?

[elfs]

A co-worker of mine is very fond of Test Driven Development, which isn’t really my thing, although I’m learning. I have a lot of respect for his code, which works. When I mentioned that, when working alone, I really enjoyed Literate Programming the look on his face couldn’t have been more clear. He said he hated Literate Programming, that there was no point to writing that much commentary.

So I’ve been doing TDD with one project, and LP with another project, and I’ve come to a rather amusing conclusion: Test Driven Development and Literate Programming are the same discipline.

There are a million analogies to programming: debugging a blank page.  Architecture.  Sculpture.  If these are strong analogies for programming, then how about this one: TDD and LP are the injection molding of programming.  Both attempt to describe the outside of the program, the shape of it, the outlines inside of which it should live, and the border over which it shall not cross.  Once you’ve written that outline, you then write a program that conforms to it.  LP does it piece by piece.  TDD does it whole-hog, checks for leaks, and goes and revises either the mold or the program and tries again.

But both are essentially the discipline of describing the program in excruciating detail, then writing the program to that description.   TDD is automated, true, and can tell you when you’ve lied to yourself; LP, in contrast, assumes that since your duty is to keep text and code in sync not only don’t you lie to yourself, you’re unwilling to lie to yourself.

There are many disciplines to programming, with “throw it at the wall and see what sticks” continuing to be the most favored among many developers.  (Believe me, I’ve worked at places where that was the official development policy).   But when you talk about constraining the specification such that you know for sure “the program is supposed to do this“, then LP and TDD are, at base, doing the same thing: describing the specification in such detail that the program ends up molded to the spec.

This entry was automatically cross-posted from Elf's technical journal, ElfSternberg.com

Comments

[shockwave77598.livejournal.com]

In embedded systems, you write high level and low level stuff at the exact same time, and grow them both until they meet and connect. The hardest thing for embedded folks to grasp is that there's no OS to do stuff for them - if they want to see if a button is pressed, they have to look at the IO port themselves.

[http://users.livejournal.com/_candide_/]

Interesting analysis, Elf!

The one thing that kept/keeps me from seeing TDD as a form of literate programming is that TDD separates the documentation/description of the program from the program's source code. I always thought that Knuth's idea for Literate Programming was that you wrote a hybrid source/document/spec, which was then separated into a TeX file and compilable source code.