views:

2007

answers:

6

Most Stackoverflow answers that I have found in regards to the Perl build process and unit testing and code coverage simply point me to CPAN for the documentation there. There's absolutely nothing wrong with pointing to CPAN modules because that's where the full documentation is supposed to reside. I've had trouble finding complete working code examples in many cases, though.

I've been searching all over the Internet for actual working code samples that I can download or paste into my IDE, like your typical tutorial "Hello World" example source code, but of an example that demonstrates the build process with unit testing and code coverage analysis. Does anyone have a small example of a complete working project that demonstrates these technologies and processes?

(I do have a small working example and I will answer my own question with it, but there are probably other SO users who have better examples than the ones I came up with.)

+28  A: 
Kurt W. Leucht
Your idea to set up a BuiltTest.PL doesn't sound good to me. Why can't you just write a script that does `Build build` and then `Build test`?
Leon Timmermans
Leon, are you suggesting a perl script that makes command line calls? If so, I'd rather not make command line calls if there is an OO way to make the calls programmatically as in the example BuiltTest.PL file.
Kurt W. Leucht
That's not necessary, see my own answer
Leon Timmermans
Got it. Thanks!
Kurt W. Leucht
One more thing to note is that there's not really a need to get Module::Build involved if you're not planning to put it on CPAN. If you just want to be able to run tests, then look at prove - http://search.cpan.org/~andya/Test-Harness-3.14/bin/prove. You could run your tests with just "prove t/".
mpeters
That's true, but being able to build a project can be useful even if you don't plan on putting it on CPAN. Especially if you're developing a whole app and not just a module. If you have separate testing and production deployments for your app, being able to "Build install" the project is great!
Adam Bellaire
Module::Build just isn't for CPAN. You can still get all the features from the various CPAN tools even if it isn't on CPAN. You can still build, test, distribute, and install it with the same process even though it is a private module.
brian d foy
To filter results in Devel::Cover I add options to `$ENV{HARNESS_PERL_SWITCHES}`. For example: `-MDevel::Cover=+ignore,.t$,+inc,/app/lib,-select,MyModule.pm` where `/app/lib` is the application-private library and `MyModule.pm` is the module under test.
Michael Carman
+9  A: 

In response to Kurt, I would propose this alternative to his BuiltTest.PL script.

use strict;
use warnings;
use Module::Build;

my $build = Module::Build->resume (
  properties => {
    config_dir => '_build',
  },
);

$build->dispatch('build');
$build->dispatch('test');

It reuses the database build by Build.PL (and thus assumes that already ran).

Leon Timmermans
Perfect! Thanks, Leon. I knew something was wrong with my example, but I'm still new to this perl build stuff myself! :-)
Kurt W. Leucht
+5  A: 

I cover this in Intermediate Perl as well as Mastering Perl. Kurt, however, has given a nice summary.

I combine all of this into a release script using Module::Release though. I type one command and it all happens.

brian d foy
+6  A: 

The fantastically helpful module-starter generates an easy-to-use skeleton project which handles module installation, creation of documentation and a good layout for module files to live in, and -- I think -- code coverage support. It's IMO a great start for any Perl module-related endeavour.

Also: using CPAN-related tools like Module::Build -- even for modules which are likely never going to be released publically -- is a very good idea.

Gaurav
+3  A: 

(disclosure: I'm the author)

Once you have everything sorted as described above, you could take the next step and use Devel::CoverX::Covered to e.g.

  • Given a source file, list the test files that provide coverage to that source file. This can be done on a file, sub routine and row level.
  • Given a test file, list the source files and subs covered by that test file.
  • Given a source file, report efficiently on the coverage details per row, or sub.

See the synopsis for concrete command line examples.

In Devel::PerlySense there's Emacs support to display the coverage information in the source code buffer (screen shot), and to navigate to/from covering test files.

jplindstrom