Re: When 100% Code Coverage Backfires

[xdg]

by changing my code to get 100% code coverage

Isn't the point of coverage to change your tests to increase coverage? Changing your logic for the sake of coverage seems backwards. (Note -- I'm not talking about changing layout of conditionals so that Devel::Cover can follow the logic.)

What your example does demonstrate is how seeking 100% coverage can help uncover faulty assumptions in either the requirements or the underlying code.

Using something like Carp::Assert or something similar might help here

I like that for clarity of intent, but of course, it's only hiding the lack of coverage of the failure of the assertion. Your assert line of code will be "covered", but the underlying logic won't.

Nevertheless, if I had to sum up your post, it would this:

Conditionals or branches that can't be covered because they always should be true (or false) should be converted into assertions instead.

And that does sound like good advice. ++

[adrianh]

Isn't the point of coverage to change your tests to increase coverage?

Nope. The point is to produce a better product.

Sometimes that'll be by spotting where you need more tests. Sometimes that'll be spotting where you have dead code, or illogical code, and fixing that. Sometimes that'll be leaving well alone.

(spot the bloke on a hobby horse - sorry :-)

[Ovid]

++

I just removed some dead code earlier today that the code coverage spotted. It was along the lines of the following:

sub foo {
  # bunch of code
  if ( $some_condition ) {
    # do a bunch of stuff
    return $something;
  }
  else {
    # do some other stuff
    croak($error);
  }
  # do some more stuff
}

That can be easy to miss in refactoring.

[adrianh]

I just removed some dead code earlier today that the code coverage spotted.

Ah the joys of legacy code :-)

I've found code coverage to be a great exploratory tool. Want to know how your application does something - just write an end-to-end test and look at the test coverage. Much easier way of getting an overview than messing around the debugger.

Informative too ("look - that critical bit of code doesn't touch the logging module. Ooops.")

[xdg]

Nope. The point is to produce a better product.

Agreed. I think I phrased it poorly.

What I meant to suggest is that changing code for the primary purpose of increasing coverage is probably not the best thing to be doing, particularly if it makes the resulting product worse. Fixing defects or cleaning up code smells uncovered while working to improve coverage is -- as you pointed out -- part of the point of doing coverage testing in the first place.

Since I generally try to follow test-driven development, I aim for 100% at the start and decreasing coverage is a helpful sign that my coding has gotten ahead of my testing.