Joel Spolsky sometimes sucks. But we already knew that...

Joel Spolsky says "100% unit test coverage" should not be a Joel Rule:

From Podcast 38: starting at [42:28]...

... "You should have a 13th thing on here: Unit Testing, 100% unit tests of all your code."

And that strikes me as being just a little bit too doctrinaire about something that you may not need.

Glyph (Mr. Twisted) nails it, about why Joel is wrong, wrong, wrong.

Deciphering Glyph: The Joel Un-test

He goes on and on about how the real measure of quality is whether your code is providing value to customers, and sure you can use unit tests if that's working for you, but hey, your code probably works anyway.

It's a pretty weaselly argument, and I think he knew it, because he kept saying how he was going to get flamed.  Well, Mr. Spolsky, here at least that prediction has come true ;-).

It's weaselly because any rule on the Joel Test could be subjected to this sort of false equivalence.

However, I think Glyph drives his argument over a cliff.  In comments, Glyph says some pretty indefensible things responding to the valid concerts of commenter Andrew Dalke:

(Note: I am butchering Glyph's comments, to make him appear ridiculous.  I would feel guilty, if it wasn't my absolute goal in life, to make everyone appear ridiculous.)

You might be right about this test being so hard to write. If so, MySQL and C++ are bad places to work, because testing there is unnecessarily difficult.

...

Should the developers stop working in C?

Yes.

Frankly, I think 100% unit test coverage can sometimes be completely at odds with delivering quality code to customers.  Completely at odds, because sometimes it takes considerable time to cover that last 1% of the code paths, and your customer are practically begging you to put that time on new functionality.

I would write the "über-Joel" rule as:

"100% unit test coverage, unless you are willing to advertise to your customers exactly which sections of code only have 99% test coverage of all the code paths"

If I was a customer, and the developer told me that the last 1% of comprehensive unit test coverage would take 20 hours of development away from new features, I would give him a pass.  If other customers are not as lenient, then the developer should make a choice between that particular customer's patronage and the effort to build a truly comprehensive test rig (in this case, 20 hours of developer time).