Unit Testing should be Viral

Posted: 4 years ago (2007-11-09 16:18:27 UTC ) / Updated: 2 years ago (2009-06-01 21:30:46 UTC )

Imported from WordPress

Originally posted on 2007-11-09 16:18:27

Those of you who have been privileged to work on projects with excellent unit tests are privileged. You probably already knew that. But for the rest of you: you're missing out.

A good project will often require testing before you're allowed to check code in.  There is usually complex and time-consuming testing that's done daily or weekly.  But the testing required for checkin usually does the most good, by far.

It keeps build breaks from happening, which is nice.  But better yet, it gets you used to unit tests catching stupid bugs. A stupid bug that the unit tests don't catch becomes an offense, something the program is doing wrong. The advice "if a bug happens, add a unit test that would catch it" seems unrealistic when you start out, but it's very realistic once good unit tests feel like the default.  You'll find yourself saying, "why isn't there a unit test for that?  It's easy," and then you know what to add.

Unit testing is another argument for the Unix philosophy of building all your interesting program logic into a command-line program and then spreading a thin GUI layer over the top. A command-line program is likely to be easy to test.  The GUI program is going to be very difficult to unit-test, if it's possible at all. There are a variety of GUI testing tools, and so far as I (or several companies I've worked for) can tell, none of them produce good, robust results.

But a thin GUI layer is easier to test than a huge mess with both GUI and program logic.  Better yet, the rest of your program can be tested with a script after every code change. The GUI and the program logic are two separate programs, so you benefit from the law that says "the difficulty of program maintenance increases far greater than linearly as program size grows".  And instead of a huge untestable lump, you have a small hard-to-test lump and a larger easy-to-test lump.

Near-universal unit testing also helps via the "broken window" theory of program maintenance -- that if a few things are obviously wrong then people will tend to imitate that.  But if everything is nicely maintained then they will tend to keep it that way. A few "broken windows" in code will tend to cause more rapid degeneration of the code.  Good unit-testing will spawn more unit tests.

So what's the upshot?  The program you're working on now probably has no unit tests at all.  Saying "make sure it's all done well" doesn't help you in the slightest.  So why am I bothering?

One reason is so that you'll set up unit testing for your next little new project.  And you should.

But also so that you'll think about dividing things up.  Write unit tests for your little corner of the code and maybe the next guy will add to them.  Divide up that huge, ugly, monstrous codebase and just unit-test tidy little corners of it.  You'll find that they grow tidier over time.  It'll be hard to add big changes like "you have to run unit tests before checkins" or "fixing bugs happens before new features", but you can still do things to clean up your bits of the code.  And maybe the better programmers in the rest of the company will take notice and start tidying up their corners, too.