.\" Automatically generated by Pod::Man 4.10 (Pod::Simple 3.35) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "Devel::Cover 3pm" .TH Devel::Cover 3pm "2018-11-30" "perl v5.28.1" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" Devel::Cover \- Code coverage metrics for Perl .SH "VERSION" .IX Header "VERSION" version 1.31 .SH "SYNOPSIS" .IX Header "SYNOPSIS" To get coverage for an uninstalled module: .PP .Vb 1 \& cover \-test .Ve .PP or .PP .Vb 3 \& cover \-delete \& HARNESS_PERL_SWITCHES=\-MDevel::Cover make test \& cover .Ve .PP To get coverage for an uninstalled module which uses Module::Build (0.26 or later): .PP .Vb 1 \& ./Build testcover .Ve .PP If the module does not use the t/*.t framework: .PP .Vb 1 \& PERL5OPT=\-MDevel::Cover make test .Ve .PP If you want to get coverage for a program: .PP .Vb 2 \& perl \-MDevel::Cover yourprog args \& cover .Ve .PP To alter default values: .PP .Vb 1 \& perl \-MDevel::Cover=\-db,cover_db,\-coverage,statement,time yourprog args .Ve .SH "DESCRIPTION" .IX Header "DESCRIPTION" 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 an indirect measure of quality. .PP 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. .PP Statement, branch, condition, subroutine, and pod coverage information is reported. Statement and subroutine coverage data should be accurate. Branch and condition coverage data should be mostly accurate too, although not always what one might initially expect. 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. .PP The \fIcover\fR program can be used to generate coverage reports. Devel::Cover ships with a number of reports including various types of \s-1HTML\s0 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. .PP It is possible to add annotations to reports, for example you can add a column to an \s-1HTML\s0 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 own. .PP The \fIgcov2perl\fR program can be used to convert gcov files to \f(CW\*(C`Devel::Cover\*(C'\fR databases. This allows you to display your C or \s-1XS\s0 code coverage together with your Perl coverage, or to use any of the Devel::Cover reports to display your C coverage data. .PP 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. .PP The most appropriate mailing list on which to discuss this module would be perl-qa. See . .PP The Devel::Cover repository can be found at . This is also where problems should be reported. .SH "REQUIREMENTS AND RECOMMENDED MODULES" .IX Header "REQUIREMENTS AND RECOMMENDED MODULES" .SS "\s-1REQUIREMENTS\s0" .IX Subsection "REQUIREMENTS" .IP "\(bu" 4 Perl 5.10.0 or greater. .Sp Perl versions 5.6.1, 5.6.2 and 5.8.x may work to an extent but are unsupported. Perl 5.8.7 has problems and may crash. .Sp If you want to use an unsupported version you will need to set the environment variable \f(CW$DEVEL_COVER_UNSUPPORTED\fR. Unsupported versions are also untested. I will consider patches for unsupported versions only if they do not compromise the code. This is a vague, nebulous concept that I will decide on if and when necessary. .Sp If you are using an unsupported version, please let me know. I don't want to know if you are just testing Devel::Cover, only if you are seriously using it to do code coverage analysis of real code. If I get no reports of such usage then I will remove support and delete the workarounds for versions of perl below 5.10.0. I may do that anyway. .Sp Different versions of perl may give slightly different results due to changes in the op tree. .IP "\(bu" 4 The ability to compile \s-1XS\s0 extensions. .Sp 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. .IP "\(bu" 4 Storable and Digest::MD5 .Sp Both are in the core in Perl 5.8.0 and above. .SS "\s-1OPTIONAL MODULES\s0" .IX Subsection "OPTIONAL MODULES" .IP "\(bu" 4 Template, and either \s-1PPI::HTML\s0 or Perl::Tidy .Sp Needed if you want syntax highlighted \s-1HTML\s0 reports. .IP "\(bu" 4 Pod::Coverage (0.06 or above) or Pod::Coverage::CountParents .Sp One is needed if you want Pod coverage. If Pod::Coverage::CountParents is installed, it is preferred. .IP "\(bu" 4 Test::More .Sp Required if you want to run Devel::Cover's own tests. .IP "\(bu" 4 Test::Differences .Sp Needed if the tests fail and you would like nice output telling you why. .IP "\(bu" 4 Template and Parallel::Iterator .Sp Needed if you want to run cpancover. .IP "\(bu" 4 JSON::MaybeXS .Sp \&\s-1JSON\s0 is used to store the coverage database if it is available. JSON::MaybeXS will select the best \s-1JSON\s0 backend installed. .SS "Use with mod_perl" .IX Subsection "Use with mod_perl" By adding \f(CW\*(C`use Devel::Cover;\*(C'\fR 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. .PP Alternatively, add \-MDevel::Cover to the parameters for mod_perl. In this example, Devel::Cover will be operating in silent mode. .PP .Vb 1 \& PerlSwitches \-MDevel::Cover=\-silent,1 .Ve .SH "OPTIONS" .IX Header "OPTIONS" .Vb 10 \& \-blib \- "use blib" and ignore files matching \ebt/ (default true \& if blib directory exists, false otherwise) \& \-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 \& cwd) \& \-ignore RE \- Set regular expressions for files to ignore (default \& "/Devel/Cover\eb") \& +ignore RE \- Append to regular expressions of files to ignore \& \-inc path \- Set prefixes of files to include (default @INC) \& +inc path \- Append to prefixes of files regular expressionsto include \& \-loose_perms val \- Use loose permissions on all files and directories in \& the coverage db so that code changing EUID can still \& write coverage information (default off) \& \-merge val \- Merge databases, for multiple test benches (default on) \& \-select RE \- Set regular expressions of files to select (default none) \& +select RE \- Append to regular expressions of files to select \& \-silent val \- Don\*(Aqt 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 if val is true (default on) .Ve .SS "More on Coverage Options" .IX Subsection "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. .PP Or, to ignore all files in \f(CW\*(C`t/lib\*(C'\fR as well as files ending in \f(CW\*(C`Foo.pm\*(C'\fR: .PP .Vb 1 \& cover \-test \-silent \-ignore ^t/lib/,Foo.pm$ .Ve .PP Note that \f(CW\*(C`\-ignore\*(C'\fR replaces any default ignore regexes. To preserve any ignore regexes which have already been set, use \f(CW\*(C`+ignore\*(C'\fR: .PP .Vb 1 \& cover \-test \-silent +ignore ^t/lib/,Foo.pm$ .Ve .SH "SELECTING FILES TO COVER" .IX Header "SELECTING FILES TO COVER" 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: .IP "\(bu" 4 If the file matches a \s-1RE\s0 given as a select option, it will be included .IP "\(bu" 4 Otherwise, if it matches a \s-1RE\s0 given as an ignore option, it won't be included .IP "\(bu" 4 Otherwise, if it is in one of the inc directories, it won't be included .IP "\(bu" 4 Otherwise, it will be included .PP 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. .PP The inc directories are initially populated with the contents of perl's \f(CW@INC\fR array. You may reset these directories using \-inc, or add to them using +inc. .PP Although these options take regular expressions, you should not enclose the \s-1RE\s0 within // or any other quoting characters. .PP The options \-coverage, [+\-]select, [+\-]ignore and [+\-]inc can be specified multiple times, but they can also take multiple comma separated arguments. In any case you should not add a space after the comma, unless you want the argument to start with that literal space. .SH "UNCOVERABLE CRITERIA" .IX Header "UNCOVERABLE CRITERIA" Sometimes you have code which is uncoverable for some reason. Perhaps it is an else clause that cannot be reached, or a check for an error condition that should never happen. You can tell Devel::Cover that certain criteria are uncoverable and then they are not counted as errors when they are not exercised. In fact, they are counted as errors if they are exercised. .PP This feature should only be used as something of a last resort. Ideally you would find some way of exercising all your code. But if you have analysed your code and determined that you are not going to be able to exercise it, it may be better to record that fact in some formal fashion and stop Devel::Cover complaining about it, so that real problems are not lost in the noise. .PP If you have uncoverable criteria I suggest not using the default \s-1HTML\s0 report (with uses html_minimal at the moment) because this sometimes shows uncoverable points as uncovered. Instead, you should use the html_basic report for \s-1HTML\s0 output which should behave correctly in this regard. .PP There are two ways to specify a construct as uncoverable, one invasive and one non-invasive. .SS "Invasive specification" .IX Subsection "Invasive specification" You can use special comments in your code to specify uncoverable criteria. Comments are of the form: .PP .Vb 1 \& # uncoverable [details] .Ve .PP The keyword \*(L"uncoverable\*(R" must be the first text in the comment. It should be followed by the name of the coverage criterion which is uncoverable. There may then be further information depending on the nature of the uncoverable construct. .PP \fIStatements\fR .IX Subsection "Statements" .PP The \*(L"uncoverable\*(R" comment should appear on either the same line as the statement, or on the line before it: .PP .Vb 3 \& $impossible++; # uncoverable statement \& # uncoverable statement \& it_has_all_gone_horribly_wrong(); .Ve .PP If there are multiple statements (or any other criterion) on a line you can specify which statement is uncoverable by using the \*(L"count\*(R" attribute, count:n, which indicates that the uncoverable statement is the nth statement on the line. .PP .Vb 3 \& # uncoverable statement count:1 \& # uncoverable statement count:2 \& cannot_run_this(); or_this(); .Ve .PP \fIBranches\fR .IX Subsection "Branches" .PP The \*(L"uncoverable\*(R" comment should specify whether the \*(L"true\*(R" or \*(L"false\*(R" branch is uncoverable. .PP .Vb 2 \& # uncoverable branch true \& if (pi == 3) .Ve .PP Both branches may be uncoverable: .PP .Vb 7 \& # uncoverable branch true \& # uncoverable branch false \& if (impossible_thing_happened_one_way()) { \& handle_it_one_way(); # uncoverable statement \& } else { \& handle_it_another_way(); # uncoverable statement \& } .Ve .PP If there is an elsif in the branch then it can be addressed as the second branch on the line by using the \*(L"count\*(R" attribute. Further elsifs are the third and fourth \*(L"count\*(R" value, and so on: .PP # uncoverable branch false count:2 if ($thing == 1) { \fBhandle_thing_being_one()\fR; } elsif ($thing == 2) { \fBhandle_thing_being_tow()\fR; } else { die \*(L"thing can only be one or two, not \f(CW$thing\fR\*(R"; # uncoverable statement } .PP \fIConditions\fR .IX Subsection "Conditions" .PP Because of the way in which Perl short-circuits boolean operations, there are three ways in which such conditionals can be uncoverable. In the case of \f(CW\*(C` $x && $y\*(C'\fR for example, the left operator may never be true, the right operator may never be true, and the whole operation may never be false. These conditions may be modelled thus: .PP .Vb 6 \& # uncoverable branch true \& # uncoverable condition left \& # uncoverable condition false \& if ($x && !$y) { \& $x++; # uncoverable statement \& } \& \& # uncoverable branch true \& # uncoverable condition right \& # uncoverable condition false \& if (!$x && $y) { \& } .Ve .PP \&\f(CW\*(C`Or\*(C'\fR conditionals are handled in a similar fashion (\s-1TODO\s0 \- provide some examples) but \f(CW\*(C`xor\*(C'\fR conditionals are not properly handled yet. .PP As for branches, the \*(L"count\*(R" value may be used for either conditions in elsif conditionals, or for complex conditions. .PP \fISubroutines\fR .IX Subsection "Subroutines" .PP A subroutine should be marked as uncoverable at the point where the first statement is marked as uncoverable. Ideally all other criteria in the subroutine would be marked as uncoverable automatically, but that isn't the case at the moment. .PP .Vb 4 \& sub z { \& # uncoverable subroutine \& $y++; # uncoverable statement \& } .Ve .SS "Non-invasive specification" .IX Subsection "Non-invasive specification" If you can't, or don't want to add coverage comments to your code, you can specify the uncoverable information in a separate file. By default the files \&\s-1PWD/\s0.uncoverable and \s-1HOME/\s0.uncoverable are checked. If you use the \&\-uncoverable_file parameter then the file you provide is checked as well as those two files. .PP The interface to managing this file is the cover program, and the options are: .PP .Vb 4 \& \-uncoverable_file \& \-add_uncoverable_point \& \-delete_uncoverable_point **UNIMPLEMENTED** \& \-clean_uncoverable_points **UNIMPLEMENTED** .Ve .PP The parameter for \-add_uncoverable_point is a string composed of up to seven space separated elements: \*(L"$file \f(CW$criterion\fR \f(CW$line\fR \f(CW$count\fR \f(CW$type\fR \f(CW$class\fR \f(CW$note\fR\*(R". .PP The contents of the uncoverable file is the same, with one point per line. .SH "ENVIRONMENT" .IX Header "ENVIRONMENT" .SS "User variables" .IX Subsection "User variables" The \-silent option is turned on when Devel::Cover is invoked via \&\f(CW$HARNESS_PERL_SWITCHES\fR or \f(CW$PERL5OPT\fR. Devel::Cover tries to do the right thing when \f(CW$MOD_PERL\fR is set. \f(CW$DEVEL_COVER_OPTIONS\fR is appended to any options passed into Devel::Cover. .PP Note that when Devel::Cover is invoked via an environment variable, any modules specified on the command line, such as via the \-Mmodule option, will not be covered. This is because the environment variables are processed after the command line and any code to be covered must appear after Devel::Cover has been loaded. To work around this, Devel::Cover can also be specified on the command line. .SS "Developer variables" .IX Subsection "Developer variables" When running Devel::Cover's own test suite, \f(CW$DEVEL_COVER_DEBUG\fR turns on debugging information, \f(CW$DEVEL_COVER_GOLDEN_VERSION\fR overrides Devel::Cover's own idea of which golden results it should test against, and \&\f(CW$DEVEL_COVER_NO_COVERAGE\fR runs the tests without collecting coverage. \&\f(CW$DEVEL_COVER_DB_FORMAT\fR may be set to \*(L"Sereal\*(R", \*(L"\s-1JSON\*(R"\s0 or \*(L"Storable\*(R" to override the default choice of \s-1DB\s0 format (Sereal, then \s-1JSON\s0 if either are available, otherwise Storable). \f(CW$DEVEL_COVER_IO_OPTIONS\fR provides fine-grained control over the \s-1DB\s0 format. For example, setting it to \*(L"pretty\*(R" when the format is \s-1JSON\s0 will store the \s-1DB\s0 in a readable \s-1JSON\s0 format. \f(CW$DEVEL_COVER_CPUS\fR overrides the automated detection of the number of CPUs to use in parallel testing. .SH "ACKNOWLEDGEMENTS" .IX Header "ACKNOWLEDGEMENTS" Some code and ideas cribbed from: .IP "\(bu" 4 Devel::OpProf .IP "\(bu" 4 B::Concise .IP "\(bu" 4 B::Deparse .SH "SEE ALSO" .IX Header "SEE ALSO" .IP "\(bu" 4 Devel::Cover::Tutorial .IP "\(bu" 4 B .IP "\(bu" 4 Pod::Coverage .SH "LIMITATIONS" .IX Header "LIMITATIONS" There are things that Devel::Cover can't cover. .SS "Absence of shared dependencies" .IX Subsection "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 function: .PP .Vb 8 \& sub foo { \& eval { require Storable }; \& if ($@) { \& carp "Can\*(Aqt find Storable"; \& return; \& } \& # ... \& } .Ve .PP You might write a test for the failure mode as .PP .Vb 3 \& BEGIN { @INC = () } \& foo(); \& # check for error message .Ve .PP Because Devel::Cover uses Storable internally, the import will succeed (and the test will fail) under a coverage run. .PP Modules used by Devel::Cover while gathering coverage: .IP "\(bu" 4 B .IP "\(bu" 4 B::Debug .IP "\(bu" 4 B::Deparse .IP "\(bu" 4 Carp .IP "\(bu" 4 Cwd .IP "\(bu" 4 Digest::MD5 .IP "\(bu" 4 File::Path .IP "\(bu" 4 File::Spec .IP "\(bu" 4 Storable or JSON::MaybeXS (and its backend) or Sereal .SS "Redefined subroutines" .IX Subsection "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 \&\s-1CV.\s0 Hints, tips or patches to resolve this will be gladly accepted. .PP The module Test::TestCoverage uses this technique and so should not be used in conjunction with Devel::Cover. .SH "BUGS" .IX Header "BUGS" Almost certainly. .PP See the \s-1BUGS\s0 file, the \s-1TODO\s0 file and the bug trackers at and .PP Please report new bugs on Github. .SH "LICENCE" .IX Header "LICENCE" Copyright 2001\-2018, Paul Johnson (paul@pjcj.net) .PP This software is free. It is licensed under the same terms as Perl itself. .PP The latest version of this software should be available on \s-1CPAN\s0 and from my homepage: http://www.pjcj.net/.