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
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.
- 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.
- 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.
- 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.''
- 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.
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?