On Sun, Nov 05, 2006 at 10:18:19PM -0500, Christopher H. Laco wrote:

> Anyone have any ideas on this blip?
> 
> http://handelframework.com/coverage/blib-lib-Handel-Base-pm.html
>    line #171
> 
> Lord knows, it doesn't really matter since that's the only piece left,
> but I'm kinda of curious. This is under Devel::Cover 0.59 under 5.8.4,
> 5.8.6, and 5.8.8

Hmmm.  It's pretty hard to tell what's going on there, but let's have a go.

The statements on that line are the ones from "use Module" being expanded to
"BEGIN { require Module; import Module LIST; }", and the subroutines are there
because BEGIN blocks are subroutines.

I count seven subroutines on that line, indicating that you used seven
separate modules there.  And there are 22 statements, which will be three for
each module plus one for the eval.

Looking at the figures for the statement coverage, starting from the first
line and looking at every third line, we have 1, 1, 1, 1, 1, 1, 441, 447.
This tells me that the first six modules were used once each, and the seventh
was used 441 times.  The 447 at the end is the eval statement, which was
naturally called once for each "use".

Interestingly, the last module, which was used 441 times, seems to have failed
twice.  You can see that from figures of 439 for the next two statements.
Similarly, the two uncovered lines you see are associated with the failure of
the third module.  But since this module was used only once, those statements
never get executed and so show up as errors.

This can be verified by looking at the next lines where you check for errors
from the eval.  Notice that the check is executed 447 times, that both the
true and false branches are executed, and that the statement reporting the
eval failure is executed three times.

So, in order to get your 100% coverage (!), all you need to do is find out
which of the modules is failing, and call it once that it doesn't fail.

Of course you might not want to do that, in which case you can just say,
"good, I know what is going on here" and let it be.  In this case you'd
ideally want to mark the code as uncoverable so that when you do get a real
coverage error you can easily notice it.  Unfortunately the code to do that is
not finished yet, and the default html report doesn't support it anyway.
You're welcome to try out what's there anyway, if you like, but remember that
it is still in development and there is no documentation for it yet, except
for the code itself.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Reply via email to