I was listening to the Stack Overflow podcast #39 last night while waiting for my daughter’s basketball game to start, and I’m pretty sure Joel just flipped the bozo bit in my mind.  He and Jeff Atwood were discussing test driven development, and Joel’s example had to do with a button in Copilot that would change the jpeg compression level, I suppose to make screen text momentarily more legible at the expense of bandwidth.  Joel then went on to complain how the resulting unit tests would dwarf the actual code.

 

The actual code would have been about 10 lines by Joel’s estimation since all it had to do was change one of the parameters to the jpeg compression library they use on this product.  The test code, however would be monstrous, requiring pre-made "after" versions of an image at varying compression levels with which to compare the results with the button in various states.  He also mentioned the problem of someone else having to test these things, and the difficulties they would encounter if their jpeg library happened to be different than what Joel was using.

 

This exchange pointed out a couple fundamental misunderstandings about how you write unit tests.  Apparantly, Joel only understands full, top-down integration tests.  The idea that I would write unit tests for something like Word, for example, by checking that the individual bits of a .doc file are affected by clicking the bold button on the toolbar illustrates a complete misunderstanding of what "unit" testing means.  You don’t test the launch systems of our nuclear arsenal by blowing something up.  See my previous post for my new favorite definition of unit testing.  Bascially, I said:

That’s what Joel doesn’t understand.  In reality, all Joel’s test needed to cover was that pushing the button changes the input parameter to the compression library.  You don’t worry about whether the compression library works, that’s not your code.  Those tests belong to the component vendor who makes the compression library.  If, for some insane reason, Fog Creek felt it necessary to write their own jpeg compression routines, then they are violating a couple of other closely-held principles of mine, and have thus flipped their collective bozo bits en masse.  I certainly hope this isn’t the case.

 

This basic misunderstanding of who owns what is illustrated by the second part of Joel’s comment, where he talks about the testing difficulties introduced if customers jpeg libraries produce different results than whatever Fog Creek was using.  Excuse me?  The customer has no more business running your unit tests than you do running the tests for the jpeg library that, God willing, you didn’t write in-house.  Why would your customers even have your tests.  Why would you have shipped them the test assemblies in the first place.  They aren’t going to need it (TAGNI?).

 

I’ve listened to Stack Overflow for a while, and I’ve found it very interesting and enlightening in most cases, but this one episode reduced my personal opinion of the hosts by several orders of magnitude.  If you don’t understand a subject, then either don’t talk about it, or have someone on who does understand it to explain it to you.  There are inexperienced developers out there who think that just because you have a podcast, then you automatically know what you’re talking about.  It’s your responsibility as a host to not do irreperable damage to your audience by convincing them that things aren’t important just because you don’t understand them.  This one episode has just armed a small army of developer luddites with a "get out of testing free" card that they will play to their pointy haired bosses, thus avoiding that whole nasty "career advancement" business.

 

Hopefully in the coming weeks some more guests will appear to set Jeff and Joel straight.  If not, then I’ll probably just stop listening.  The bozo bit is, however, very hard to un-set.  Years ago something Rockford Lhotka said flipped his bozo bit in my mind, and I still have a hard time taking him seriously today.  The thing is, I can’t even remember what it was that he said now.  Yeah, that’s how sticky the bozo bit is.