Devel::Cover recommendations... or maybe not?

[Matt Wilson]

On 3/14/07, Paul Johnson <paul at pjcj.net> wrote:
> Here are some reasons why perfectly good code might not have 100%
> coverage from my cpancover output:
>
>  - My specific combination of hardware, operating system, configuration,
>    installed software or some other variable, doesn't allow some of the
>    code to be exercised.

I'll agree with that - sometimes OS-specific code can't be completely covered.

>  - Some configuration might be needed to run all the tests.

Surely that's the point, though? Write your unit tests explicitly so
that your configurations are going to achieve maximum coverage.

>  - The author performed a manual test, or in some other way convinced
>    themselves that the code was good, and considered their precious time
>    might be better used somewhere else.

Heh, and that just flies in the face of unit testing. "Works for me"
is rarely a useful reply for somebody who can't get your code to work
for them.

>  - Devel::Cover might have bugs.

It does, definitely. We've used it extensively - all our internal
modules have it running against them daily to ensure we have high
coverage - and there are definitely a few internal gotchas. However,
all in all it's pretty good.

> In the case of the Test module which looks the worst,
> Test::WWW::Selenium, the reason for the low coverage, if I recall
> correctly, is that part of the module is automatically generated from
> some XML which also generates code for Java, Python, C# and Ruby (that
> list is probably wrong), and the Perl module doesn't need most of the
> generated functions, so they aren't tested.