Test-Driven Development: A Bad Example

23:59 Mon 05 Oct 2009
[, , ]

Test-Driven Development (TDD) is a programming methodology that calls for programmers to first write tests that will only be passed by code that meets the specifications for whatever component they’re working on, and then to write the code for the component and keep working on it until it passes the tests.

I don’t tend to use Test-Driven Development, even though I often think I should. When working on personal projects, I don’t even write many tests after the code is done, and that’s something I should definitely do. But I generally regard it as a good practice.

That being said, it’s not a cure-all, or even a “best practice” in the sense of being something that every programming team should use all the time. I think it’s likely to significantly aid code maintainability, particularly on larger projects, but can still imagine circumstances where it makes sense not to insist on it.

I also think that, as with so many other methodologies, whether someone uses it or not doesn’t tell you much about their ability as a programmer. An unfortunate example of this is covered by Peter Seibel, in a blog post discussing some of the responses to comments on TDD (and unit tests in general) in his book Coders at Work. The whole thing is fairly interesting, but the bit I found fascinating starts after the text “The only interviewee”[*]. This gets into a discussion of how Peter Norvig and Ron Jeffries differed in their approaches to writing a program to solve Sudoku problems. Norvig did it the “traditional” way, i.e. he immediately started trying to write code that would solve the problem. Jeffries, not incidentally one of the founders of Extreme Programming, started out writing tests first.

That Norvig solved the problem in one essay and about 100 lines of Python, while Jeffries gave up after five blog posts, doesn’t actually tell us anything about TDD and its efficacy (even if it does look somewhat bad). But it does demonstrate that use or advocacy of that methodology doesn’t tell you much about someone’s ability to solve a programming problem in any particular domain. Is that news? It certainly shouldn’t be, but from time to time the buzz around these things gets out of hand and people seem to need reminders that there aren’t many reliable shortcuts to figuring out how much a given programmer is going to contribute to a given project.

I haven’t read Coders at Work yet, but it’s on my list.

[*] It’s long been a peeve of mine that you can’t link directly into the section of an HTML document that you want to hit unless it happens to have an id attribute, and I’ve always thought that every piece of HTML-generating software should sequentially tag paragraphs to support that functionality. I will eventually write a WordPress plugin that makes WordPress do this.

Leave a Reply