First question is, do you use Test::More's improvements? I find that the standard Test module covers basic tests pretty well. No sense using Test::More unless you need it.

If you decide that you truly need Test::More's added flexibility, you can add a PREREQ_PM attribute to your WriteMakefile() call in Makefile.PL. It's a hashref, with the names being the module names and the values being the version number required for your script to run. Version number '0' means 'Any version'. Here's what it would be for a module called 'Devel::Refactorizer':

WriteMakefile(
    'NAME'              => 'Devel::Refactorizer',
    'VERSION_FROM'      => 'Refactorizer.pm', # finds $VERSION
    'PREREQ_PM'         => { 'Test::More' => 0}, # e.g., Module::Name 
+=> 1.1
    ($] >= 5.005 ?    ## Add these new keywords supported since 5.005
      (ABSTRACT_FROM => 'Refactorizer.pm', # retrieve abstract from mo
+dule
       AUTHOR     => 'A. U. Thor <a.u.thor@a.galaxy.far.far.away>') : 
+()),
);
[download]

Truth in advertising: much of what I'm saying here is stuff I'm reading from the documentation right now for the first time. :)

If you were to install this module using CPAN, it would first attempt to do a 'make' on the distribution. This attempt would fail, since the Makefile will complain about lacking the Test::More module. Then, the CPAN module would download Test::More, build it, and then re-run 'make' on the Refactorizer. CPAN runs 'make test' after 'make', so Test::More would be in place for the tests.

Another approach: some folks bundle Test::More along with their module distributions. I personally think that this method clutters CPAN; observe what happens when you search for Test::More with search.cpan.org. However, it's a fairly small module, and some pretty bright people take this approach, so YMMV.

stephen

Thank you! This sounds like exactly what I wanted to know. If I really need Test::More or not is a very valid question, but now I feel safer with taking that desicion if I feel I do need it. :)

I guess that is the same question that I did ask, should I use a standard module or not - one of the criteria should definetely be "do I really need this?". Good point indeed.

You mention that you read the documentation, could you please tell me where it is also? I looked through all the - what i thought - normal places for this, and couldn't find it. It is possible I have a small Sunday brain damage, so I'd appreciate it. :)

I don't think I'll bundle it anyways, which means that one possibly still have a problem with non-CPAN installs, but heck, people will just have to read the README for once then. They should anyways. :)

Again, thank you for the reply!

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

I searched for 'PREREQ_PM' in both the CPAN module documentation and the ExtUtils::MakeMaker docs. I always enjoy questions like this because, well, now I know too. :)

stephen

I find Test is quite adequate. If you want you can bundle a copy of Test::More or even Test::Lincoln::Stein in your distro to avoid this problem. Asking permission for Test::More would be politic. See the CGI distribution to see Lincoln Stein roll his own test suite and include it. If you want complex tests you can have them just using Test:

use Test;
BEGIN { plan tests => 42 }
use Widget;

ok(1) # module loaded OK

my $w = new Widget;

$reply = $w->method;
@reply = $w->method;
ok( $reply );
ok( @reply );
ok( $reply =~ m/something/ );
ok( $reply eq 'some string' );
ok( scalar @reply == 42 );
ok( join '', @reply eq 'some list of stuff' );
[download]

When you make a disto start like this:

$ h2xs -X Foo::Bar
[download]

This will write module stubs for you automatically. You will get:

Foo/Bar/Makefile.PL
Foo/Bar/Bar.pm
Foo/Bar/Changes
Foo/Bar/test.pl
Foo/Bar/MANIFEST
Foo/Bar/README
[download]

You should then rename the Bar direcory Foo-Bar-0.01 if you want to follow the norms. You throw away the Foo dir :-) This writes you the stubs of your code which you can then just edit! Note if you just h2xs -X Bar then you will avoid generating the extra directory but you will need to edit your Makefile.PL it will have:

    'NAME' => 'Bar'

    # but you need
  
    'NAME' => 'Foo::Bar'
[download]

Package like this:

$ tar -cf Foo-Bar-0.01.tar Foo-Bar-0.01
$ gzip Foo-Bar-0.01.tar
[download]

Test like this:

$ tar -xzvf Foo-Bar-0.01.tar.gz
$ perl Makefile.PL
$ make
$ make test
$ make install
[download]

You will find that when you are playing with your distro you will repeat a number of steps over and over. I have a little script called make_manifest.pl which does a whole lot of things like:

• clean out blib/ and all the other Makefile and make crap
• remove any temp files like .bak files (or any other extensions like .pbp ~ etc)
• cleans Win32 line endings to *nix standard (otherwise you will have install nightmares)
• writes HTML files into html/ for all the pod (with CSS support) using Pod::HTML
• writes a current MANIFEST

Finally use Carp; see Carp for why and use the carp() and croak methods instead of warn() and die() which will put these messages in the perspective of the caller rather than the module.

Good luck.

cheers

tachyon

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

First off, I do know that I can accomplish the same things with Test, even though I like the richer interface of Test::More better, and it makes the tests easier to read. A matter of taste, and "do I need it", and probably other things too. :)

That said, I am impressed by the richness of your response, and I see that there are lots of gold here for when modules should start hitting the world. Thanks! Lots of it is not new, but it is a good summary, in good context.

I guess I could bundle whatever module I need like that, but I think I would rather have it as a prerequisite, or use one that the installer is sure to have.

And I will take a look at that script - no use in reinventing the wheel on that one. :)

Again, thank you. I will have use for this. :)

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

I just expanded it to a tutorial:

How to make a CPAN Module Distribution

cheers

tachyon

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

Like you I'm beginning to look into using an XP-like unit-test framework in Perl, so the timing of your question here was good for me.

I think if you are personally going to see advantages from Test::More then you should use it. It may help you get that release out there, and asking people to install it before your module isn't overly unreasonable. It does look to be a generally useful module, you're not going to be the only one now looking down that way, and the user gets the advantage of potentially more stable code if you like your test tool.