If you're not a developer or don't work closely with developers, you might want to skip this space today.  If you want to stick around, feel free, but prepare for a crash course.

If you haven't noticed, we're developing things quickly.  The entire project has gone from the initial checkin to a near-launch status in about 10 weeks.  70 days.  That's it.  When you consider that we've had to bring together a completely distributed team, recruit people to fill holes, continuously clarify and improve specifications, and generally work to keep everything moving smoothly, it's kind of amazing... but even all of that leaves out one of the key aspects:  Unit Testing.

I've worked on numerous projects where Unit Tests cover just a few percent of the code.  Unforunately, it tends to be the norm and most of us have gotten used to it.  When we change code, we know we're taking risks.  We don't always acknowledge it, but we know that we're likely to break other things.  More interestingly, there's always that lurking suspicion that we'll change the behavior of something that breaks something else completely unrelated and some arbitrary point in the future... and suddenly become "the guy who broke everything".  No one wants to be that guy.

That's why Unit Testing (and the accompany metric, Code Coverage) is so important.  Before I change anything, I need to know what does and does not work.  Hopefully no one is commiting broken code, but I digress...  While I make my change, I need to know that it works as expected.  When my change is complete, I need to know that I haven't broken other things.  I need to know that the code is at least as good as what I started with if not better.  Or at the bare minimum, I need to know if my change just made someone else's life difficult.

But here's the problem.  When you already have 10, 20, or 100kloc, there's no way you can write Unit Tests or even consider writing tests for the whole thing, so what do you do?  Quite simply, you triage:

1. First, don't make your problem worse.  As you add new functionality, write the corresponding tests.
2. Next, patch what you have.  When you find a bug and go to fix it, write tests for the bug.  If you're really brave, you'll probably think of a few other tests to write.  Do it.  It's hard to write too many tests.
3. Finally, identify the core pieces that the most important.  You probably have a handful of classes/methods that everything else depends on.  If those are broken, your application dies.  So start there.  Even more fun... when you need to bring a junior guy into the team, Unit Testing is a great way to gain understanding and may allow him to fix bugs.  Everyone wins.

So now you're probably wondering what our Unit Tests look like.  Valid question and this image summarizes it nicely.  To put it quite simply: about 7 of every 10 lines of code has a test associated with it.  Yes, we have plenty of room for growth.

Just remember that Code Coverage is not the same as Code Quality...