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

[Nicholas Clark]

On Fri, Mar 16, 2007 at 02:10:20AM +0100, Philippe Bruhat (BooK) wrote:

> One problem with test coverage is that you also cover code that is
> not used at all in production. With a large piece of software that has
> been in use for years, I'm quite sure that there are some large pieces
> of dead code (or even dead modules!) that could be removed, and that
> this removal would be beneficial for the whole system. The test suite

IIRC I sent Paul a patch, which was incorporated in 0.58 or so, to ignore
coverage outside subroutines. I never actually ended up using it on the
then-work code, but the intent was that running the report with this should
show you totally uncovered modules, by avoiding the false reassurance of
coverage that happens to only be because of things like setting $VERSION

I was hoping to find a more honest assessment of completely untested modules,
but it would also make modules unused in production stand out like sore
thumbs.

> doesn't help in this case: it continue to be the only script actually
> using these dead modules! (if you have tests for that code, that is)
> 
> So, I'm thinking about (that's a long term project for $work, not
> something for anytime soon) running a staging server under Devel::Cover,
> and feed the system with traffic from production, just to see the actual
> pieces of code that are exercised by real production traffic.
> 
> And then have a look at the code that is never ever run...

The other thing I did once was log all the classes coming in over the SOAP
interface to a daemon, and work out what classes it could generate internally
with bless(). The union of the two revealed all the classes it needed.
I forget the set term for the inverse of that, but it's all the classes that
the daemon never needs to load. (Which if nothing else needs, may be
delete-able. All software is hateful - help reduce the hate)

Nicholas Clark