Optionally include in reports files that aren't touched at all by tests #43

DrHyde opened this Issue Jan 24, 2013 · 4 comments


None yet
3 participants

DrHyde commented Jan 24, 2013

My test suite is so bad that some modules in my project aren't just badly covered, they're not touched at all. And so they don't show up in reports from Devel::Cover. I'd like to have them show up.

Something like this would be nice:

$ cover -select_dir lib

to force it to report on every .pm file under the lib/ directory.


pjcj commented Jan 26, 2013

I like this idea in principle, and some way to report on totally unused file has been requested before. The biggest problem here is that if the file has never been compiled, Devel::Cover can't really know anything about it - other than it exists. So this means that reporting on this file would only be able to tell you that it exists and hasn't been compiled.

I can see a few of options here:

  1. I could just list these files separately and provide no other information.
  2. I could fake up coverage data so that the files would appear along with the other covered files, but they would appear to have no coverable elements.
  3. I could try to compile the file so that I could actually report of the coverable elements.

The main problem with the first two options is that they would not affect the overall coverage values, so it would be possible to have 100% coverage whilst still have files that have not even been compiled.

The main problem with the third option is that it may not work and would need to fall back to one of the other options.

I'm somewhat concerned that people who could benefit most from this option may not know about it, but I'm not sure that trying to turn it on by default is a good idea.


DrHyde commented Jan 27, 2013

Listing them in the main index with a brief explanation would be a good start. As for affecting the overall coverage values - surely we all know to read the report and not just look at the executive summary :-) Perhaps you could just refrain from reporting an overall %age if there are uncovered and uncompilable files.

I agree that turning it on by default would be a bad idea. Quite often I'll only run part of my test suite - just the bits for the new feature I'm adding, for example, or for the code I'm debuggering - but will still want coverage reports for just those tests. If it were to then bitch about eleventy squillion other files in lib/ or blib/ that haven't been touched, I think I'd get annoyed quite quickly! And anyway, that assumes that you can know where to look for untouched files. I don't think that in the general case you can, especially for in-house applications that are never destined for the CPAN and so could have all kinds of screwed up directory structures.

yko commented Sep 19, 2013

I suggest to allow user to disable collection of the coverage at runtime. A pragma or a function would work.
The idea is that the code author might provide a list of fiels and Devel::Coverage will initialize an empty coverage for them.
An example:

# t/init_coverage.t
use Test::More;
plan skip_all => 'coverage init skipped' unless ${INC}{"Devel/Coverage.pm"};
plan tests => 1;


# Replace with find lib -name '*.pm' output
require $_ for @_;

ok "coverage init complete";

Those files that won't be loaded by tests within the test rount should have zero coverage on all metrics.
The question is if it's technically possible.

yko commented Sep 19, 2013

By looking into the code I managed to find solution that works for me as described in previous comment

Maybe there is a better way to do this via proper -coverage flag (none?).
This approach might worh to be documented (Devel::Cover::Tutorial?).

use strict;
use warnings;
use Test::More tests => 1;
  # Tell Devel::Cover do not record coverage at all

use AllYourPackages;
# In my case I replace this line with the output of `find . -name \*.pm`
# But whatever works for you

pass "coverage initialized";

# At this point Devel::Cover aware of all your packages
# and initialized coverage into zeros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment