Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^2: When 100% Code Coverage Backfires

by adrianh (Chancellor)
on Mar 26, 2007 at 14:26 UTC ( #606585=note: print w/ replies, xml ) Need Help??


in reply to Re: When 100% Code Coverage Backfires
in thread When 100% Code Coverage Backfires

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 :-)


Comment on Re^2: When 100% Code Coverage Backfires
Re^3: When 100% Code Coverage Backfires
by Ovid (Cardinal) on Mar 26, 2007 at 14:44 UTC

    ++

    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.

    Cheers,
    Ovid

    New address of my CGI Course.

      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.")

Re^3: When 100% Code Coverage Backfires
by xdg (Monsignor) on Mar 26, 2007 at 16:07 UTC
    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.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://606585]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2014-12-27 07:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls