use Perl

• what's really wrong with use_ok? (Score:1)

  by markjugg (792)

  I see the value of having a test script which reality-checks that everything compiles, especially if there are big gaps in a test suite.

  But I don't see what's wrong with "use_ok()" for a module that you neede to "use" anyway. It's hardly any more syntax. What's the harm?
  • Re: (Score:2)

    by Ovid (2709)

    First, here's the general 'correct' incantation:

    BEGIN {
        use_ok 'Some::Module' or die "Cannot use Some::Module";
    }

    If the module is not used in a "BEGIN" block, compile-time behavior is ignored (e.g., exported functions may alter how your code parses).

    If you don't have the 'or die' (or BAIL_OUT), things can get even worse. If the module fails to load, but most of it compiled, you can get partially compiled code loaded. Your 'use_ok' failure may scroll off the screen but failures show up much l
    • Re:what's really wrong with use_ok? summary (Score:1)

      by markjugg (792)

      So I would say it summarizes like this:

      If "use" a module it fails, the test grinds to a halt, which is nearly always a reasonable result.

      With "use_ok", the test may /continue/ causing unexpected results later on, because the module is not loaded, or worse, partially loaded.

      Thanks for your clarification, Ovid.
• I generally use... (Score:1)

  by mauzo (8185)

  something like

  #!/usr/bin/perl
  
  use strict;
  use warnings;
  
  use Test::More;
  
  my $tests;
  
  BEGIN { $tests += 3 }
  use_ok 'Clone::Closure';
  can_ok 'Clone::Closure', 'clone';
  ok !main->can('clone'), 'clone not exported by default';
  
  BEGIN { $tests += 2 }
  use_ok 'Clone::Closure', 'clone';
  can_ok 'main', 'clone';
  
  BEGIN { plan tests => $tests }
  
  BAIL_OUT('module will not load')
      if grep !$_, Test::More->builder->summary;

  as t/00use.t and then just use the modules after that. I'm deliberately ignoring the
  • Re: (Score:2)

    by rjray (1649)

    This is similar to my approach, though I don't usually test for specific functions or methods. Once I've established that the modules can load, I leave it to individual suites to test specific modules.

    (But then, I also arrange my suites so that no suite is dependent on a module that hasn't already been vetted by a previous suite. I'm just anal-retentive that way...)

    --
    

    --rjray
• Load the modules in dependency order, too! (Score:1)

  by mugwumpjism (1871)

  Problem with this approach is that you don't know when errors are raised which module raised them; it might have been a dependency of the ones which you loaded. Here's one I wrote recently;

  use Test::More qw(no_plan);
  
  use FindBin qw($Bin);
  use File::Find;
  
  my @modules;
  my %uses;
  
  finddepth(sub {
          m{^\w.*\.pm$} && do {
                  my $module = $File::Find::name;
                  $module =~ s{.*/lib
• Test::Compile (Score:2)

  by gabor (1626)

  In Padre I have the following code:

  use strict;
  use warnings;
  
  use Test::More;
  plan skip_all => 'Needs Test::Compile 0.08' if not eval "use Test::Compile 0.08; 1";
  diag "Test::Compile $Test::Compile::VERSION";
  all_pl_files_ok(all_pm_files());

  The funny call at the end is because currently Test::Compile has all_pm_files_ok() that "use"-es all the pm files while all_pl_files_ok() runs "perl -cw path/to/module" on all modules.

  The above combination provides the strongest way to check if every module can be com

  --
  

  • Test automation using Perl [szabgab.com]
  • there's also Test::UseAllModules (Score:1)

    by ishigaki (7238)

    I've been using Test::UseAllModules (since 2006) which reads MANIFEST and tries to load every .pm module under "lib" directory, and if anything should fail, the test would bail out.

    A sample code is like this:

        use strict;
        use warnings;
        use Test::UseAllModules;

        BEGIN {
            all_uses_ok();
        }

    The point is you don't need to find modules as it should be done by ExtUtils::Manifest when you ship the package.
• bug: my $DIR = 'lib/'; (Score:1)

  by markjugg (792)

  There's a bug here that I didn't spot until I tried to run it:

    my $DIR => 'lib/';

  I think you mean "=" there, not =>
  • Re: (Score:2)

    by Ovid (2709)

    Agreed. Thanks for spotting that!