Well, if you are writing a module and you use h2xs -X -n amodulename you get several files, one of which is a test file (in the /t folder). Consider the following (fake) module Conquest::MegaGoogle:

type conquest-megagoogle.t
# Before `make install' is performed this script should be runnable wi
+th
# `make test'. After `make install' it should work as `perl Conquest-M
+egaGoogle.t'

#########################

# change 'tests => 1' to 'tests => last_test_to_print';

use Test::More tests => 1;
BEGIN { use_ok('Conquest::MegaGoogle') };

#########################

# Insert your test code below, the Test::More module is use()ed here s
+o read
# its man page ( perldoc Test::More ) for help writing this test scrip
+t.
[download]

So the idea is to have a test script that uses the Test module. (perldoc Test will clarify things a bit)

I mention this in the framework of creating a module because you may consider trying to place a lot of those smaller scripts in an actual module. This will make your maintenance a lot easier. After all of the functionality is neatly tucked away you can use GetOpt::Long or something to manage command line parameters.

Scripts normally are:

easier to lose across implementations

confusing due to lots of duplicated parameters (e.g. -i means something different in prog2 than in prog1)

redundant. Lots of them duplicate code unnecessarily (because objects have to be reloaded every prog)

Celebrate Intellectual Diversity

Comment on Re: Setting up tests for cat-type filter programs Download Code