Michael G Schwern wrote:
On Mon, Mar 07, 2005 at 07:45:39AM -0700, Jim Cromie wrote:
Theres another issue: coverage can depend upon presense of other modules,
ex Test::Warnings, being installed on testers boxes, those tests would be skipped otherwise,
and perceived coverage would suffer.
That's ok. The overall coverage report can show the union of all reports for that version of the module. This will produce more accurate coverage reports since it will allow the results from multiple platforms to be combined.
For example, if you do a coverage analysis of MakeMaker or Module::Build on Unix all the non-Unix code will appear to be uncovered. But if you combine the results from several different machines you'll get all the code.
are MM or MB analyses posted anywhere for general perusal ?
That'd be cool, but how does this merge/combining magically happen ? More specifically, Ive found it to *not* be happening when I spawn off an `$^X -MDevel::Cover -e $testcode` job, as you've noted in another thread. OTOH, it does seem to merge repeated runs of 'make testcover', as I see the ran-this-line counts in the coverage report go up after each run.
so, wrt merging coverage results, I looked inside cover_db/cover.12,
a storable file w multiple runs, one for each t/*.t file, each with a unique key:
$ mst -d cover_db/cover.12 |egrep -e 'run|111'
'runs' => {
'1110216257.25137.60188' => {
'run' => 't/pp-dump.t',
'1110216248.25129.46205' => {
'run' => 't/labels.t',
'1110216234.25117.50538' => {
'run' => 't/basic.t',
'1110216267.25145.50509' => {
'run' => 't/warns.t',
'1110216241.25123.18273' => {
'run' => 't/honorLocals.t',
'1110216253.25133.53184' => {
'run' => 't/new.t',
'1110216255.25135.61883' => {
'run' => 't/pod.t',
'1110216260.25139.29174' => {
'run' => 't/speed.t',
'1110216229.25107.07159' => {
'run' => 't/alias.t',
'1110216250.25131.38534' => {
'run' => 't/multiarg.t',
'1110216243.25125.33249' => {
'run' => 't/indent-terse.t',
'1110216239.25121.64393' => {
'run' => 't/emulate.t',
'1110216226.25105.54436' => {
'run' => 't/01_use.t',
'1110216262.25141.01103' => {
'run' => 't/twoObjects.t',
'1110216265.25143.07361' => {
'run' => 't/useoptions.t',
'1110216231.25109.28610' => {
'run' => 't/autoprint.t',
'1110216246.25127.34447' => {
'run' => 't/initobj.t',
'1110216236.25119.49831' => {
4111,
'run' => 't/chains.t',
the file doubles in size when I rerun `make testcover`. It would be easy enough to lump them together, though by itself, this wouldnt help identify platforms where a module is undertested.
anyway, we need site-space and cpu-time somewhere to merge the data.
