This is part 3 in the module that allows a developer to test how well the tests of a distribution actually check the code of a distribtion. The second blog delved into the development process of making the module. And in its simplest use, it looks like this:
CODEuse Code::Coverage;
my $coverage = Code::Coverage.new(
targets => @targets,
runners => @test-scripts
);
$coverage.run;
say .key ~ ": " ~ .value for $coverage.missed;
At object instantiation, provide two named arguments.
The first one is called
targetsand should contain theusetargets for which to provide coverage information. These use targets are usually thekeyof theCode::Coverableobject returned by thecoverablessubroutine of theCode::Coverabledistribution.
In the
Test::Coveragecase, this would be obtained from the "provides" section from theMETA6.jsonfile of a distribution.
The second one is called
runners, and it should contain the path(s) of the scripts that should be executed to create coverage information.
In the
Test::Coveragethat would be set up with all the.tand.rakutestfiles in thetandxtdirectories of the distribution.
Then, call the
runmethod on theCode::Coverageobject to execute the scripts and create the coverage information, scan and process it.
After that, you can call one of several report methods, such as
missed, which will then report the line numbers of the code that was not covered.
Multiple runs
Sometimes you may want to run the same script multiple times, but with different arguments, to get complete coverage information. And you can! Just call the
runmethod once again, and specify any command line arguments as arguments torunmethod:
CODE$coverage.run("foo");
$coverage.run("bar");
After each call, the coverage information is updated and you can call any of the report methods again.
If the different code paths depend on environment variables, you should just set those in the
%*ENVvariable:
CODE%*ENV<FROBNICATE>=1
$coverage.run; # run with frobnication
Annotations
It is always nice to know the line numbers of code that didn't get covered. But that would still be a lot of looking up and down the code to find out what the contents was of the lines that didn't get covered.
To make that process easier, the
Code::Coverageobject has anannotatedmethod that will produce the source code of ausetarget, and prefix each line of source with one of these four possibilities:
- "
*" - line was coverable, and covered
- "
✱" - line was not coverable, but covered anyway
- "
x" - line was coverable and not covered
- "
" - line was not coverable
Looks familiar? It should be if you've read the first post of this blog series! Yes, that's indeed the logic that
Test::Coverageuses to create the.rakucovfiles.
More control
The would mean a great deal to me!
↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
Ähnliche Beiträge
Auch interessante Nachrichten Creating coverage information
Thematisch verwandte Begriffe: Creating, coverage, information · 6 Treffer
OpenAI Confirms AI Agents Wrote to Multiple Internet Sites in ‘Wiki Incident’
Click, Click… Boom! Automating Protections Testing with Detonate
Claude Code Observability with OpenTelemetry
Videos werden geladen ...
Beiträge werden geladen ...
Videos werden geladen ...
Beiträge werden geladen ...
Videos werden geladen ...
Beiträge werden geladen ...
Videos werden geladen ...
SOCIAL SHARE CARD GENERATOR