Filewatcher File Search File Search
Content Search
» » » » » libdevel-cover-perl_0.89-1_kfreebsd-i386.deb » Content »
pkg://libdevel-cover-perl_0.89-1_kfreebsd-i386.deb:208166/usr/share/man/man3/  info  control  downloads

libdevel-cover-perl - Perl tool for determining code coverage metrics…  more info»


Devel::Cover(3pm)User Contributed Perl DocumentatioDevel::Cover(3pm)

       Devel::Cover - Code coverage metrics for Perl

       version 0.89

       To get coverage for an uninstalled module:

        cover -test


        cover -delete
        HARNESS_PERL_SWITCHES=-MDevel::Cover make test

       To get coverage for an uninstalled module which uses
       Module::Build (0.26 or later):

        ./Build testcover

       If the module does not use the t/*.t framework:

        PERL5OPT=-MDevel::Cover make test

       If you want to get coverage for a program:

        perl -MDevel::Cover yourprog args

        perl -MDevel::Cover=-db,cover_db,-coverage,statement,time yourprog args

       This module provides code coverage metrics for Perl.  Code
       coverage metrics describe how thoroughly tests exercise code.
       By using Devel::Cover you can discover areas of code not
       exercised by your tests and determine which tests to create
       to increase coverage.  Code coverage can be considered as an
       indirect measure of quality.

       Although it is still being developed, Devel::Cover is now
       quite stable and provides many of the features to be expected
       in a useful coverage tool.

       Statement, branch, condition, subroutine, and pod coverage
       information is reported.  Statement coverage data should be
       reasonable.  Branch and condition coverage data should be
       mostly accurate too, although not always what one might
       initially expect.  Subroutine coverage should be as accurate
       as statement coverage.  Pod coverage comes from
       Pod::Coverage.  If Pod::Coverage::CountParents is available
       it will be used instead.  Coverage data for other criteria
       are not yet collected.

       The cover program can be used to generate coverage reports.
       Devel::Cover ships with a number of different reports
       including various types of HTML output, textual reports, a
       report to display missing coverage in the same format as
       compilation errors and a report to display coverage
       information within the Vim editor.

       It is possible to add annotations to reports, for example you
       could add a column to an HTML report showing who last changed
       a line, as determined by git blame.  Some annotation modules
       are shipped with Devel::Cover and you can easily create your

       The gcov2perl program can be used to convert gcov files to
       "Devel::Cover" databases.  This allows you to display your C
       or XS code coverage together with your Perl coverage, or to
       use any of the Devel::Cvoer reports to display your C
       coverage data.

       You may find that the coverage results don't match your
       expectations.  This could be due to a bug in Devel::Cover,
       but code coverage can be unintuitive to newcomers, and
       especially so with Perl, so you may want to reconsider your
       expectations as well.

       Code coverage data are collected by replacing perl ops with
       functions which count how many times the ops are executed.
       These data are then mapped back to reality using the B
       compiler modules.  There is also a statement profiling
       facility which should not be relied on.  For proper profiling
       use Devel::NYTProf.  Previous versions of Devel::Cover
       collected coverage data by replacing perl's runops function.
       It is still possible to switch to that mode of operation, but
       this now gets little testing and will probably be removed
       soon.  You probably don't care about any of this.

       The most appropriate mailing list on which to discuss this
       module would be perl-qa.  Discussion has migrated there from
       perl-qa-metrics which is now defunct.  See

       The Devel::Cover repository can be found at

       ·   Perl 5.6.1 or greater.  Perl 5.8.8 or greater is

           Perl 5.7 is unsupported.  Perl 5.8.8 or greater is
           recommended.  Perl 5.8.7 has problems and may crash.
           Whilst Perl 5.6 should mostly work you will probably miss
           out on coverage information which would be available
           using a more modern version and will likely run into bugs
           in perl.  Different versions of perl may give slightly
           different results due to changes in the op tree.

       ·   The ability to compile XS extensions.

           This means a working C compiler and make program at
           least.  If you built perl from source you will have these
           already and they will be used automatically.  If your
           perl was built in some other way, for example you may
           have installed it using your Operating System's packaging
           mechanism, you will need to ensure that the appropriate
           tools are installed.

       ·   Storable and Digest::MD5

           Both are in the core in Perl 5.8.0 and above.

       ·   Template, and either PPI::HTML or Perl::Tidy

           Needed if you want syntax highlighted HTML reports.

       ·   Pod::Coverage (0.06 or above) or

           One is needed if you want Pod coverage.  If
           Pod::Coverage::CountParents is installed, it is

       ·   Test::More

           Required if you want to run Devel::Cover's own tests.

       ·   Test::Warn

           Some of Devel::Cover's own tests require it.

       ·   Test::Differences

           if the tests fail and you would like nice output telling
           you why.

       ·   Template, and Parallel::Iterator

           Needed if you want to run cpancover.

   Use with mod_perl
       By adding "use Devel::Cover;" to your mod_perl startup
       script, you should be able to collect coverage information
       when running under mod_perl.  You can also add any options
       you need at this point.  I would suggest adding this as early
       as possible in your startup script in order to collect as
       much coverage information as possible.

        -blib               - "use blib" and ignore files matching \bt/ (default true
                              iff blib directory exists).
        -coverage criterion - Turn on coverage for the specified criterion.  Criteria
                              include statement, branch, condition, path, subroutine,
                              pod, time, all and none (default all available).
        -db cover_db        - Store results in coverage db (default ./cover_db).
        -dir path           - Directory in which coverage will be collected (default
        -ignore RE          - Set REs of files to ignore (default "/Devel/Cover\b").
        +ignore RE          - Append to REs of files to ignore.
        -inc path           - Set prefixes of files to ignore (default @INC).
        +inc path           - Append to prefixes of files to ignore.
        -merge val          - Merge databases, for multiple test benches (default on).
        -select RE          - Set REs of files to select (default none).
        +select RE          - Append to REs of files to select.
        -silent val         - Don't print informational messages (default off).
        -subs_only val      - Only cover code in subroutine bodies (default off).
        -replace_ops val    - Use op replacing rather than runops (default on).
        -summary val        - Print summary information iff val is true (default on).

   More on Coverage Options
       You can specify options to some coverage criteria.  At the
       moment only pod coverage takes any options.  These are the
       parameters which are passed into the Pod::Coverage
       constructor.  The extra options are separated by dashes, and
       you may specify as many as you wish.  For example, to specify
       that all subroutines containing xx are private, call
       Devel::Cover with the option -coverage,pod-also_private-xx.

       You may select the files for which you want to collect
       coverage data using the select, ignore and inc options.  The
       system uses the following procedure to decide whether a file
       will be included in coverage reports:

       ·   If the file matches a RE given as a select option, it
           will be included.

       ·   Otherwise, if it matches a RE given as an ignore option,
           it won't be included.

       ·   Otherwise, if it is in one of the inc directories, it
           won't be included.

       ·   Otherwise, it will be included.

       You may add to the REs to select by using +select, or you may
       reset the selections using -select.  The same principle
       applies to the REs to ignore.

       The inc directories are initially populated with the contents
       of the @INC array at the time Devel::Cover was built.  You
       may reset these directories using -inc, or add to them using

       Although these options take regular expressions, you should
       not enclose the RE within // or any other quoting characters.

       The -silent option is turned on when Devel::Cover is invoked
       via $HARNESS_PERL_SWITCHES or $PERL5OPT.  Devel::Cover tries
       to do the right thing when $MOD_PERL is set.
       $DEVEL_COVER_OPTIONS is appended to any options passed into

       When running Devel::Cover's own test suite,
       $DEVEL_COVER_DEBUG turns on debugging information,
       $DEVEL_COVER_GOLDEN_VERSION overrides Devel::Cover's own idea
       of which golden results it should test against, and
       $DEVEL_COVER_NO_COVERAGE runs the tests without collecting
       coverage.  The environment variables described in this
       paragraph are of interest to Devel::Cover maintainers only.

       Some code and ideas cribbed from:



       There are things that Devel::Cover can't cover.

   Absence of shared dependencies
       Perl keeps track of which modules have been loaded (to avoid
       reloading them).  Because of this, it isn't possible to get
       coverage for a path where a runtime import fails if the
       module being imported is one that Devel::Cover uses
       internally.  For example, suppose your program has this

        sub foo {
            eval { require Storable };
            if ($@) {
                carp "Can't find Storable";
            # ...

       You might write a test for the failure mode as

        BEGIN { @INC = () }
        # check for error message

       Because Devel::Cover uses Storable internally, the import
       will succeed (and the test will fail) under a coverage run.

       Modules used by Devel::Cover while gathering coverage:

       ·   B

       ·   B::Debug

       ·   B::Deparse

       ·   Carp

       ·   Cwd

       ·   Digest::MD5

       ·   File::Path

       ·   File::Spec

       ·   Storable

   Redefined subroutines
       If you redefine a subroutine you may find that the original
       subroutine is not reported on.  This is because I haven't yet
       found a way to locate the original CV.  Hints, tips or
       patches to resolve this will be gladly accepted.

       Almost certainly.

       See the BUGS file, the TODO file and the bug trackers at

       Copyright 2001-2012, Paul Johnson (

       This software is free.  It is licensed under the same terms
       as Perl itself.

       The latest version of this software should be available on
       CPAN and from my homepage:

perl v5.14.2                 2012-06-15            Devel::Cover(3pm)
Results 1 - 1 of 1
Help - FTP Sites List - Software Dir.
Search over 15 billion files
© 1997-2017