Kevin's Weblog

I recently came across a link for this article: How to Misuse Code Coverage, about how not to use code coverage tools. (Interestingly it was in another person’s meditation on this idiom.) It’s pretty good, and cogently explains the vague feelings I’ve had keeping me away from certain parts of our code where I know I could trivially up the code coverage, but wouldn’t really test the important things (which, sadly, I don’t have time to write tests for at this point).

Apparently Boston’s T is planning to start searching passengers, out of increased worries due to the upcoming Democratic National Convention. The ACLU is protesting. I had a few thoughts on the matter.

• First, when will civil libertarians ever learn that the way to get support is not to say things like, “Well, you know, people do use illegal drugs, and maybe they forget that they have a joint in their backpack, and those people are going to get in trouble if they get searched.”?
• This won’t be universal searches, which would cripple the system. Rather they will be “random” searches, with all the usual concerns that brings.
• I’m not the first to say this, and I won’t be the last, but I’m really sick of hearing people say, “things are different after 9/11”.
• You really can’t say things like, “This is meant to be a deterrent. Nobody believes we’re going to approach 100% with this.” You’ve basically just told would-be wrongdoers, “we probably won’t catch you”. Deterrance only works if the chance of getting caught is high and the penalties are sufficiently severe. You have to figure that a possibly suicidal attacker is extremely tough to deter.
• Does this mean you’re not going to be able to travel on the T with a *gasp* pocketknife anymore?

There are days when I become totally disheartened and convinced that I’m the only person around here who actually tests their code. Somehow it seems that every time I take a nearly-finished project and start work on integrating it into the main code-line, I find that various tests are failing, leaving me to track down why exactly and find the person who made the change to confirm if it is a bug or an evolution that invalidates a test assumption. Since I’ve typically unit-tested my code pretty thoroughly by this point, I nearly always spend significantly more time dealing with other people’s bugs than fixing any problems I find in my code.

Given this, I have to wonder why I bother writing test frameworks, writing convenience wrappers, writing convenience wrappers to the convenience wrappers, writing documentation for the test systems, setting up nightly test runs and reports, giving talks about the test systems, coming to meetings to consult on the use of the test systems, harping on the unit tests (or, more typically, lack thereof) in code reviews, etc.

sigh...