Your thoughts seem to focus on setting up data structures. That is IMHO wrong. You should focus on setting up a simple harness structure. You don't need (or probably want) a data structure for your tests. You want simple. You want easy. You want quick. You want understandable. You don't need easily modifiable as if the tests were valid in the first place they should always pass, thus you almost never delete from a test suite, you only add. It is also a hell of a lot easier to find a test if each test has its own chunk of code.... I would have one test script per script. Typically you call these test files 'prog_or_module_name.t' and put them in a t/ directory. Here is a suggested simple framework:

#!/usr/bin/perl -s

use Test;
BEGIN{ plan tests => 3 };

my $prog = 'script.pl';
our $TMPFILE = '/tmp/tmpfile' . time();
my ( $input, $output, $opt );

# make sure program exists or we are bound to fail
ok( -e $prog );  #1

# make sure we can write to our tmpfile
ok( write_tmpfile('') );    #2
END{ unlink $TMPFILE };     # clean up at end

# tests go here

$input  = '';
$output = '';
$opts   = '';
ok( test_prog( $prog, $input, $opts ), $output );  #3

# .....


# we could use open2 or open3 but why complicate it....
sub test_prog {
    my ( $prog, $input, $opts ) = @_;
    write_tmpfile( $input );
    my $actual_output = `cat $tmpfile | $prog $opts`;
  return $actual_output;
}

sub write_tmpfile {
    open F, '>$TMPFILE' or return 0;
    print F $_[0];
    close F;
  return 1;
}
[download]

All you need to do to add a test is copy the input/output/opts/ok stub and fill in the blanks. As you find bugs you just add yet another test case. Assuming you go for the t/*.t format you can make a little shell or perl script like this:

[root@devel3 t]# cat run
#!/bin/sh
/usr/bin/perl -e 'use Test::Harness qw(&runtests); runtests @ARGV;' /s
+ome/path/t/*.t
[download]

And then just call run to run all your tests. UpdateFixed typo, thanks blyman

If you're just reading in one input, piped, and producing one output then it seems like a simple job.

Simply store the input for each program in a text file, and the output. Then use redirection and diff.

For example you could use:

#!/bin/sh
cat data/test1.in | prog1 > data/test1.tmp
diff data/test1.out data/test1.tmp
[download]

That's the general idea. Pipe in the input, and redirect the output to a temporary file. Then compare that with the expected output.

Rewriting that to iterate over a list of commands and data files, and using perl is a simple enough job I'm sure.

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]

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:

There are many ways to do this. I'm wondering what nice idioms people have come up with for this. Nice properties of a test harness would be that it keeps the input and expected output data (which can be fake, usually) in a nicely plain text, easy to read and easy to edit format.

A bit late in the day - but if you've not found it already Test::Chunks handles this rather nicely.