On Tue, Aug 17, 2004 at 06:22:13AM -0700, Jim Keenan wrote: > Two days ago I uploaded the most recent version of my > module List::Compare to CPAN. This was the first > version in whose development I used Paul Johnson's > Devel::Cover to analyze the test suite's coverage of > the module's code and, as a result, over 3300 tests > were added, both to test new code and to test older > code more thoroughly.
Wow! > The first thing I noticed after using Devel::Cover was > how much output it generates. The HTML files depicting > the line-by-line status of the coverage are enormous. You think they are large now ... :-) > As an alternative, I generated a plain-text file like > so: > > cover cover_db -report=text > LC_coverage_20040814.txt > > Even that file was large. Since my coverage was fairly > good to begin with, what I *really* wanted was a > smaller file which reported on the uncovered elements. > I took two approaches: (1) hacking up a Perl script > which parsed the plain-text report; (2) manually > cutting-and-pasting the uncovered elements into a new, > much smaller plain-text file. For example, I edited > the file so that only subroutines with uncovered > branches were printed out. > > But I wondered: Wouldn't be easier to pass options to > 'cover' so that a report focusing on uncovered items > would be generated? Is this possible now? The > documentation for cover's options is, to say the > least, very terse, and I can't tell whether it can > DWIW. At the moment, no, there is no option to do what you want. > So: Can Devel::Cover's 'cover' program be used to > generate reports of uncovered > statements/branches/conditions/only? What you want to do (no really, you do) is to write a new report which only reports on the uncovered constructs. Or maybe an option to the existing report(s) is a better solution. Or maybe an interactive backend is the real solution, using Tk, or Gtk, or Wx, or CGI or whatever. I have deliberately made it as easy as possible to write new backends in the hope that people would do so when the need arose. The trouble is that Michael made the current default report so nice that most people don't even consider the need for something different. But writing a new backend is fairly simple. It's probably easiest to copy from one of the existing ones - Text is the shortest and clearest. There is an API to access the coverage data, you can pass in options from cover, and with the backend in the Report subdirectory it can be called from cover. If anyone wants to write a new backend, I'd be happy to include it in the distribution, or for you to release it separately. Just be aware that the main reason I still call the code alpha is because there may still need to be API changes. Hopefully only minor ones or backwards compatible ones now though. So I'm afraid that at the moment there is nothing to do what you want, and your options range from cover -report text | grep '\*\*\*' through to writing a full blown gui backend. By the way, how big is enormous? I had never expected the size of the HTML output to be a problem, but it obviously is to some people. The current output is much smaller than that from the report that I originally wrote. I don't think there's much scope for reducing its size without also reducing the content. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
