5.3 Feature & Refactoring Triage

My recommendation is to triage your app while you write it because I have yet to meet the person who found writing tests for an existing app to be anything but a chore. If you've come into a project that's already got a lot of untested code this approach still works just as well, if not more so, but do yourself a favor and write tests while you're writing the code and it's still fresh in your mind. You and I both know that it just feels like work to have to go back and write them later.

Minor

is well, minor. Mostly this is code that you have high confidence in, is so simple that the odds of it breaking are low, and if it does break it's more of an inconvenience than anything else.

Complex

code is not necessarily mission critical but it is more prone to breaking than a simple loop. If you can refactor it into a set of simple routines do so. If not, you should probably test it because the more complicated something is the greater the chance that you, or your coworkers can screw it up. We're human. We screw stuff up; accept it and take measures to prevent it.

Critical

code is ``mission critical''. If that code breaks your app is screwed. Your customers will start brandishing hatchets and leave your site in droves. Your investors will reconsider participating in your next round of financing. This code is critical. There is no excuse for not testing this. You don't need to imagine me smacking you up-side the head for this one. Some real person will do it for me when they find out you just crossed your fingers and hoped that ``it looked like it was working'', actually meant ``i know for a fact that it's working.''

Morgue

would be for old dead code that should really be culled. Either it no longer works, it's been commented out, or it's no longer touched by any part of the system. Get rid of it. If you ever need it again it's in your version control system. Leaving it in only makes your system harder to maintain or your code harder to read (because you're skipping over all the commented out sections). In the instances where you are culling code from a working class you may want to leave yourself a note that, ``removed code that used to do foo. `` and include some reference to the revision / tag / whatever in your VCS where it was last seen.

So, before you write the first line of the function, take a second to ask yourself if you've got your head wrapped around what you're doing enough that you could write the unit test for it right now, or if writing the unit test would help you to understand what you need to code in the function. If you answer yes to either of these then go write the test, then write the function. But, I know you. You're going to skip this at least half the time. Bad developer! No cookie! So, with TDD being skipped (``just this once, really. I promise'') for this function we need to triage what we write. If you finish this and move on to anything else without first triaging it I shall, once again, smack you up-side the head. If I'm not around you're going to have to promise to do it yourself. TRIAGE IS NOT OPTIONAL. Got it?

If your triage comes up critical you write the test for it now. No checking your e-mail. No surfing. Do it Now. If you have to leave, get someone else to write it now or take other measures to guarantee it will be written before you touch another line of code. Do whatever it takes. This code is critical to your apps survival.

If your triage comes up complex you really ought to write a test for it. Putting it off is a bad idea because that introduces the possibility it won't get done.

If your triage comes up minor it's a judgment call. How confident are you about it? Are you sure it'll be trivial if it does break?