runrig has asked for the wisdom of the Perl Monks concerning the following question:

When you put a module on CPAN, it searches your distribution for any "*.pm" files and they are displayed when you search for any module in your distribution. What if you have a module in the distribution which is only used in the test suite (the 'make test'), and you'd rather not have them show up as actual modules for installation?

I'm opting for distributing the module with a ".pt" extension, then renaming it during the 'make test'. I'm wondering if there's a better way to do it, or just other options, if there's something I've missed from ExtUtils::MakeMaker or somewhere else... (The module is Parse::FixedLength if you're curious).

Update: This post is no longer relevant. CPAN no longer seems to list libraries in a sub-directory of the t directory.

  • Comment on Including a 'test only' module in distribution

Replies are listed 'Best First'.
Re: Including a 'test only' module in distribution
by tachyon (Chancellor) on Sep 25, 2001 at 22:52 UTC

    Why does your test suite need to be a module? Almost by definition it needs to be one or more perl scripts that use Parse::FixedLength as the object of the exercise is to test your actual module(s) in the context it/they will be used.

    I presume you are using h2xs as recommended to generate your basic module component stubs and directory structure: 

    C:\>h2xs -X  -n Parse::FixedLength
Writing Parse/FixedLength/FixedLength.pm
Writing Parse/FixedLength/Makefile.PL
Writing Parse/FixedLength/test.pl
Writing Parse/FixedLength/Changes
Writing Parse/FixedLength/MANIFEST
C:\>

    [download]

    These stubs contain all the basic files/code for your distro which makes life easier.perlman:perlxstut is not a bad read. It has a C focus but the intro sections are applicable to any module and cover a bit on testing.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[reply]
[d/l]
      The test suite itself is not a module. One of the tests (well, two actually) use a module that inherits from the main module and exists only to test a certain feature of subclassing the main module.

      And I generated the whole thing with h2xs, and I deleted test.pl and put several test scripts in a 't' subdirectory as per the docs, and my 'test' module is buried in the 't' directory and gets found via a 'use lib' and statement in the relevant test scripts.

      Sorry if I was unclear...

      Update:The test scripts don't actually explicitly use the test module themselves, but the module gets use'd from within the main module via arguments in the import list or the constructor method of the main module (and this whole process is what I'm testing), so the test module needs to be a ".pm" file and the path to it needs to get into @INC.

      I don't like the way I currently have it with the test scripts themselves renaming the file, so I've lately decided to put 'use lib' statements in the test scripts, and put this after the WriteMakeFile() in Makefile.PL:

      find( sub {
    return unless /^FLTest.pt$/;
    return if -f "FLTest.pm";
    copy("FLTest.pt", "FLTest.pm")
      or die "Couldn't create FLTest.pm (some tests will fail): $!";
}, ".");

      [download]
[reply]
[d/l]

        You still don't need to use a module to do this. All you need is a package which can live quite happily in a script. Here is a HTML::Parser example - Filter inherits from Parser, including its new method as you can see. This works fine within a package structure so you don't need a separate module. It's a rather basic tag filter that only passes specified tags and their content if you were wondering. 

        package Filter;
use strict;
use base 'HTML::Parser';

my ($filter, $want_it);
my @ok_tags = qw ( h1 h2 h3 h4 p br );
my %ok_tags;
$ok_tags{$_}++ for @ok_tags;
 
sub start {
    my ($self, $tag, $attr, $attrseq, $origtext) = @_;
    if ( exists $ok_tags{$tag}) {
        $filter .= $origtext;
        $want_it = 1;
    } else {
        $want_it = 0;
    } 
}

sub text {
    my ($self, $text) = @_;
    $filter .= $text if $want_it; 
}

sub comment {
    # uncomment to no strip comments
    # my ($self, $comment) = @_;
    # $filter .= "<!-- $comment -->";
}

sub end {
    my ($self, $tag, $origtext) = @_; 
    $filter .= $origtext if exists $ok_tags{$tag};
}

my $parser = new Filter;
my $html = join '', <DATA>;
$parser->parse($html);
$parser->eof;

print $html;
print "\n\n------------------------\n\n";
print $filter;

__DATA__
<html>
<head>
  <title>Title</title>
</head>
<body>
<h1>Hello Parser</h1>
<p>You need HTML::Parser</p>
<h2>Parser rocks!</h2>
<a href="html.parser.com">html.parser.com</a>
<hr>
<pre>
  use HTML::Parser;
</pre>
<!-- HTML PARSER ROCKS! -->
</body>
</html>

        [download]

        cheers

        tachyon

        s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[reply]
[d/l]

        Why not just avoid needing the Test.pm module at all by taking the 'test' module's code and wrapping it in a BEGIN block at the top of the test script and removing the 'use Test' (or whatever) statement currently being being used?

[reply]
Re: Including a 'test only' module in distribution
by Zaxo (Archbishop) on Sep 26, 2001 at 17:27 UTC

    Class::DBI places some test modules in a subdir t/testlib. CPAN does not list these as packages of the distribution. I don't see much special treatment in the build files, so perhaps the extra level of depth is all that's needed.

    After Compline,
    Zaxo

[reply]
      The test modules don't show up in the result list of the initial search but they do show up when you click on the result itself (the Actor, Director, Film, Lazy, and OtherFilm modules are the test modules). I suppose the general consensus must be that's its not important enough to worry about :-)

      Update (2012): Sometime after this was posted, the problem seems to have been resolved. I think CPAN no longer lists libraries in the t sub-directory

[reply]

Back to Seekers of Perl Wisdom