I don't really need any convincing that having a good set of unit test cases is helpful. I don't strictly practice Test Driven Design. Sometimes I write the code prior to the test cases, especially when the task is sufficiently rote that I don't really have to design it. However, I don't like having too much code without test coverage and this evening is why.
I've been having to do quite a bit of refactoring of my query engine. The problem is simple enough, given the size of the data set and the number of queries, each generation of query results will take way too long. So, I've been inserting some sampling techniques to get approximate results without running the full set.
That's great, but if I didn't have my test cases all automated, I'd be pretty concerned that I'm breaking things as I re-write them. With the test cases well defined and easily run after each change, it's a fairly stress-free endeavor. Make the change, run the tests, see what broke, fix it. As I'm pretty good at keeping my line count in any one method to single digits, I'm rarely more than five lines away from spotting the culprit.
Unfortunately, not everybody views things this way. We've had an outside consulting company write a bunch of code for us at work. It's well-written code; these folks are good. However, we have darn near zero test coverage. That means that if we change it (which we certainly will), we'll need to go through full-blown debugging cycles. I don't like the prospects of that, so I've put a halt on new development while we get some decent test coverage developed.
Very few developers enjoy writing tests. I get that. Frankly, neither do I. But, as the guy on the hook if a change comes in late, (or, worse, if a defective change makes it to production), I've learned to like it more than the alternative.
No comments:
Post a Comment