You’ve done a thorough code review with your team and your code has come out with a few nice improvements. Good. You know that many a trustworthy source have speculated code reviews find as many as two times the number of defects that testing does. So you might suppose going to the trouble of creating automated tests, simply for your own devices, might be a bit overkill. As it turns out, it is worth it, and it’s going to save you a lot of time in the long run. Why is it so valuable?

Indulge me in a brief aside… I saw Full Metal Jacket recently on cable for the up-teenth time; the first act of the film, the part that is set on Paris Island, is hard for me to flip away from. I usually end up catching at least the first quarter of the movie. If you’ve seen it, you’ll probably remember the part where the main characters recite, as new recruits, the Marine Corps prayer – it ends with “Without me, my rifle is useless; without my rifle, I am useless.” I think the prayer metaphorically makes sense if developers were reciting it and replaced the rifles with their automated tests.

To figure out why, let’s answer the burning questions that first come to mind:

Why should a developer care about doing their own testing?

1. It alerts you of problems (duh).
2. You’ll have a check in place in case a bug ever comes back to life.
3. It gives you the opportunity to fix things before anyone else finds out about them.
4. It’s the best way to demonstrate that your code meets its requirements!

Why don’t you want testers (or worse, end users) to find your bugs?

First of all, let’s be honest, this is an ideal to strive toward, even though actually achieving 100% test coverage and catching every possible bug is a definite pipe-dream. But we have to keep in mind that bugs discovered by people other than a developer cause a lot of speculation, confusion, and in general, overhead work for everyone – time that could be better spent doing more productive things. We’d like nothing better than to hand testers (and ultimately users) squeaky-clean code. What happens if we don’t? (and you won’t!)

Imagine taking a class of third graders outside to find an insect in the “wild” and learn about (not burn) it with a magnifying glass. You’re even able to get everyone to concentrate long enough to take a peek at a would-be critter. The first candidate you find turns out to be a piece of bark that looks like a beetle. As you’re searching for another, two of your students get in a fight over claim to a partially decomposed boot they find. Another gets a nose bleed. When you finally manage to find another potential insect, you pass it over, mistaking the critter for a leaf. Little do you know it is actually a very well camouflaged member of the family Phyllidae. By this time a child has fallen face first into a mud puddle and another has peed in his pants (which, one would think, should start to attract some insects).

Imagine that you do manage to find an insect in the wild; how would you get the whole class to observe it properly? There’s just one magnifying glass. The moment you get it under the glass, it darts away. It’s a struggle to keep track of. Not everyone is going to have a good viewing angle. If it disappears, then it might just as well be dead to you (did you hear that tree fall in the woods?).

Enough already with the horrible analogy? Okay, okay. The comparison of users to third graders in our thought experiment was purely coincidental – but you get the point. Having a group of people focus on a moving bug in “the wild” is tough! It’d be much easier to bring a captured critter into a controlled class environment to observe - our analog of a bug that we have caught with nifty our automated test net.

Bug Detective?

Given the fact that a tester’s job is to find defects, odds are sometimes you’ll get a defect report filed that looks like it’s written in cuneiform and requires a wizard’s hat, cauldron and lizard eyeballs to reproduce it. Sometimes a tester might not be giving you a legit bug – sometimes. There are a few scenarios that come to mind:

1. A requirement is incomplete, misunderstood, miscommunicated or changed.
2. An external system was down.
3. An admin fat fingered something.

This comes with the territory and you’re just going to have to suck it up. You’re ultimately the gumshoe on the case. A good way to think of it is that testers and users are like the police of our system – they’re responsible for being the first on the scene, drawing chalk outlines, “booking” the suspects we arrest, etc. What the tester is explaining is probably going to confuse you at least a few times before it makes sense. If you have good testing support, this might not be that painful. But you could have the Super Troopers on the case, and each clue that comes in is going to waste more and more of your time. And heaven forbid an end user finds this problem, and then tries to communicate this to a support rep – your job then becomes ten times harder because you have to decode 2-3 levels of miscommunication that’s occurred. Sometimes no good comes of all this, sometimes you find and squash a bug. In cases where you don’t know what to do, write some tests – ask what the outcome should be, let the answers create more questions and more tests. And be sure to hold onto them!

Whatever the outcome, because good developers are lazy, we want more than anything else to prevent this from ever happening again. Worse case, you’ve spent a lot of time addressing something and should have at least a documented set of work you’ve done and decisions made. Make sure others know about this. Best case, you are able to add an automated test so you don’t have to think about this ever again (or tell anyone about it - you’ll know the moment when something goes wrong).

Conclusion

So let’s recap –

1. Bugs that slip to production are costly!
2. Automated tests help us exercise code before and after it goes into production.
3. If we work on a defect, our automated test net can help us catch a bug, or examine something that looks like a bug more closely.
4. Whenever we work on a bug (even if it’s something that isn’t truly a bug, but is being tracked as one) we should do our best to produce an automated test so we don’t have to reinvestigate in the future. A test beats an email- or source control commit-trail any day!