Scott Wang wrote:
Hi Chris,
I am still confus.
For example,
On my Linux box, I have a module "/tmp/experiment/lib/module_to_test.pm" to be tested, and I have two Perl
unit test scripts "/tmp/experiment/tests/test1.pl" and '"/tmp/experiment/tests/test2.pl" to load
the module_to_test.pm module and execute the subroutines in it. Then, what are exact "perl -MDevel::Cover"
commands I could use to get the module_to_test.pm module code coverage data from running test1.pl and test2.pl unit
test scripts? I am new in Perl, appreciate your detail information.
Scott:
With all due respect, I think your confusion is self-inflicted. You
acknowledge that you are new to Perl and to Devel::Cover in particular,
but you are trying to do things in a way (a) that would take an
experienced Perl programmer a lot of time to hack up; and (b) that an
experienced Perl programmer would not even bother with. Why not?
Because experienced Perl programmers know that the Perl community
worldwide has expended considerable effort developing certain standard
practices which work right out of the box.
In particular, experienced Perl programmers, when developing and testing
a module, structure the module's distribution in a particular way.
Using your directory names:
/tmp/experiment/
README
MANIFEST
Makefile.PL # or Build.PL if using Module::Build rather than
# ExtUtils::MakeMaker
lib/
Module_to_test.pm
t/
test1.pl
test2.pl
You can achieve this directory and file structure a number of ways: the
h2xs utility that ships with CPAN; CPAN module ExtUtils::ModuleMaker
(which I maintain); or CPAN module Module::Starter (maintained by
Ricardo Signes). Whichever you choose, note that the directory in which
the test files sit is called 't/' -- not 'tests/'. If you use this
structure, and if in your test*.pl files you use the functionality
provided by Test::Simple or Test::More, then you are already set up to
do coverage analysis with Devel::Cover.
Why? Because Devel::Cover is set up to work on top of
ExtUtils::MakeMaker's 'make test' or Module::Build's equivalent command.
And they in turn are set up to activate Perl's Test::Harness, which in
turn is set up to play nicely with Test::Simple and Test::More.
You are frustrating this demonstrably successful approach in two ways:
(1) You are calling the directory in which your test scripts reside
'tests/' rather than 't/'. An experienced Perl hacker could go into
Test::Harness and MakeMaker and make this substitution work -- but a
Perl beginner cannot. And, as mentioned above, the experienced Perl
hacker wouldn't bother with this, because she knows that the standard
approach does what she wants.
(2) You imply that your company requires you to use its own testing
harness rather than Perl's standard Test::Harness-based approach. Why?
More to the point, even if your company requires you to use its own
harness at some point in the development cycle, why does this prevent
you from using Perl's standard approach at the point with which you're
concerned: coverage analysis?
If you use the directory structure described above and use Test::Simple
or Test::More (or anything else built on Test::Builder), then getting
coverage stats is a snap (cf my original posting in this thread for
details).
Jim Keenan
