Tests, and Bug Fixes

“Bug fixes must include a test that exercises the bug, and the fix
This really shouldn’t be controversial, y’know? I mean, after all
  1. 1. There is a bug. We all know there is a bug. There is clearly something bad happening (“Why did the service restart? I didn’t ask it to do so!”), and bad is not good.
  2. 2. If we’re lucky, the bug even comes with a test case that exercises the bug (“Send in an int instead of a string, and watch the fun!”)
  3. 3. If we’re very lucky, the bug report includes code (“To dream the impossible dream…”)
Regardless of where one is in the spectrum above, once you admit to yourself that there is a bug — and this can be an awfully hard admission to make sometimes — then you’re going to have to fix the damn thing. And that is going to involve some level of process where you’ll be doing something to make sure that there is a bug, right?
After all, taking the above in reverse order
  1. 1. If the bug report had code in it, well, you already have the beginnings of what you need to do. Just add it to the relevant test suite (unit, regression, whatever), and proceed.
    Yes, yes, I know. It’s not that simple, the code is poorly written, you need to document it, whatever. I mean, frankly, the likelihood that there is any code at all is just about as high as your actually complaining about having to document it, so let’s not go there, hmmm?
  2. 2. Mind you, of course, the bug report didn’t have code in it. It never does. But hey, you do have the test case that shows you how to exercise the bug. All you’re doing is automating this, right? And yeah, if you can’t automate it (“We don’t have any way to test what happens when a node goes down!”), well, that is a pretty significant issue too, right? You probably want to file that as a bug, and take care of it. Because, after all, how d’you know that there aren’t other bugs lurking there — it is a black hole in your test coverage, isn’t it?
  3. 3. And then you have the mystery bug report (“WhyTF is it crashing?!!!?1?”). You do you, and figure out why. And then, well, just go ahead and do everything from -2- immediately above, no?
Think of it this way. If you’re a crappy developer (ok, not you. It’s someone else), then you’re going to have a lot of bugs. Adding a test to each bug-fix, by default, is going to help you fix the bugs, and simultaneously up your code coverage! And if you’re a Rockstar Developer, then you probably are already doing this, and don’t have any issues whatsoever, right?
So yes, every time you fix a bug, include a test that exercises the bug, and the fix. It’s not that complicated, and it really, really, is going to make your life easier in the long run!

Comments

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

Cannonball Tree!

Visualizing Prime Numbers