I suppose I should talk about this. It’s Joel Spolsky’s own transcript from his podcast talking about unit testing. Now, I normally like reading Spolsky, but he does have a history of saying kind of strange things about Agile methods, so I guess it’s no surprise that he says some weird things about unit tests and TDD. I should say that I’m going off just the transcript here, but I’m reasonably confident that Spolsky wouldn’t take his own comments out of context.

There’s part of this argument that I can’t really disagree with—in the end, it is about real business needs. In my experience, having a TDD-built test suite, makes it easier to make changes later.

Anyway, here’s Joel..

But, I feel like if a team really did have 100% code coverage of their unit tests, there’d be a couple of problems. One, they would have spent an awful lot of time writing unit tests, and they wouldn’t necessarily be able to pay for that time in improved quality.

That may be true in some contexts, but I’ve been on multiple Rails projects that kept close to 100% without anybody on the team feeling that we were spending a lot of wasted time on tests. The key here, I suspect, is going test-first, which really does make writing the tests much less effort than retrofitting tests is. I agree that going back after the fact and writing up to 100% would be a pain—which is why I don’t do that. (I also think that languages that are less open than Ruby make 100% test coverage more trouble than its worth.)

I mean, they’d have some improved quality, and they’d have the ability to change things in their code with the confidence that they don’t break anything, but that’s it.

That’s it? That’s it? That’s huge. The ability to change code with confidence is the core of being able to meet future business needs. It surprises me that Spolsky writes that off so flippantly.

Also, my own experiences with Ruby code (mine and others) is that code written with TDD is of noticeably higher quality. Again, that’s because of the way TDD encourages good software structure probably more than the existence of the tests in and of themselves.

if you really have a lot of unit tests, the amount of investment you’ll have to make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.

This is a somewhat legitimate point. Although I rarely find it to be a huge burden in TDD code, I have had real problems along this line in systems that were doing other kinds of testing—actually, that’s an interesting story I should tell some day. It is true, though, that significant code refactoring will cause tests to break, and that can be a pain.

Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles.... Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture’s sake. It doesn’t seem like you could actually get any code written if you’re spending all your time writing 8,000,000 unit tests, and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge, where you spend six months defining 1000 little interfaces.

Inside that ellipses is a somewhat separate mini-rant on overly fiddly OOD principles, most of which I agree with in general. I can’t really speak to Martin’s recent work (Though I do see that he’ll be a keynote at RailsConf this year…). I do think it’s odd that Spolsky is ranting about SOLID principles while linking to an essay of Martin’s that doesn’t contain the word SOLID. The essay Spolsky linked to has what seems to be to be pretty basic OO precepts, or at least general architectural guidelines. Martin also seems to be writing about basic Design By Contract stuff. I’ve always thought Design By Contract was overly formal, but it’s hardly as alien or new as Spolsky makes it sound.

The reference to Beck, though is really weird. (Beck agrees.) Beck is, like, the high priest of “You Aren’t Going To Need It”, which is the XP mantra against architecture for architecture’s sake. I seriously have no idea where Spolsky gets this about Beck, it’d be like saying Philip Glass wrote music with notes for notes sake. (Note, I spent way too much time thinking up a good analogy, but strongly doubt I’ve got the optimal one.)

Anyway, to the extent I have larger points, it’s a) Test-Driven development improves code quality in ways other then the obvious, and b) in my experience, it’s possible to to testing such that it isn’t a drag on development.