Monthly Archives: June 2012

Partial test coverage

Software, it’s a mean scary world full of monsters just waiting to get you.

By which I mean everything is nice and cozy when coding away on a cool new feature within the four walls of your company. But there is a whole world of bugs and performance problems and security holes and confused users out there just waiting to pounce.  Just let that code into the wild they whisper.  Give it a basket of goodies and a red hood and send it out the door.

Which is why we write tests.

Tests are windows that let us see the monsters lurking outside.  That monster has a big mob of users, better not let this feature out the door until it can run extra fast.  Those hackers like our basket of goodies, lets give this feature some more layers of protection … and a flamethrower.

One of the projects I work on has about 10% test coverage.  When tests break or need upgrading someone (clearly of the non-test writing persuasion) will ask, “why should we spend time adapting the tests to the new code?”

Because, it may just be one window, I can only see part of the back yard but at least I can see a few things.  Sure, you can always go out the door and look around; maybe there’s nothing out there. With at least one window, if anything really big is lurking about, you’re sure to see part of it.

Is that a tail?

Advertisements