I'm copying the contents into perlmonks in case the website disappears some day.

Minimal Example for Test::Harness
The Test::Harness module is part of the standard perl distribution. It
+ is widely used for testing modules. Learn to use the module by study
+ing this simple example.

Mymodule.pm
    A very silly module to test. Here it is:

package Mymodule;
sub Mysub
{
  return "This is my expected output\n";
}
1;

Myapp.pl
    Silly use for a silly module.

#!/home/toma/perl5i/bin/perl

use strict;
use Mymodule;

my $result= &Mymodule::Mysub();
print $result;

tst.pl
    This program calls the tests. Some applications read the contents 
+of the t directory and call all the tests there. That way you don't h
+ave to keep updating this file when you add a new test.

#!/home/toma/perl5i/bin/perl

use strict;
use Test::Harness;

my @tests;
push @tests, qw ( t/tst1.t t/tst2.t );

runtests(@tests);

t
    This is the directory where the tests are traditionally located. E
+ven though they are perl programs, they have the file extension '.t'.

t/tst1.t
    This test doesn't really test the module, but it shows you how a t
+est is expected to succeed.

use strict;

print "1..2\n";
print "ok 1\n";
print "ok 2\n";

t/tst2.t
    This test actually looks at what the module returns to see if it i
+s correct. Test programs such as these can print all sorts of extra g
+arbage. The harness just looks for a few regular expressions that sho
+w success or failure.

#!/home/toma/perl5i/bin/perl
use strict;
use Mymodule;

my $result= &Mymodule::Mysub();
print $result, "\n";
print "You can print all kinds of garbage in your test\n";

print "1..2\n";
if ($result =~ /This is/i) { print "ok 1\n" } 
    else {print "not ok 1\n"}
if ($result =~ /expected/i) { print "ok 2\n" } 
    else {print "not ok 2\n"}

print "Anything that makes sense at the time\n";

t/tst3.t
    This one fails the second and third tests.

#!/home/toma/perl5i/bin/perl
use strict;
use Mymodule;
 
my $result= &Mymodule::Mysub();
print $result, "\n";
print "You can print all kinds of garbage in your test\n";
 
print "1..3\n";
if ($result ne "") { print "ok 1\n" } 
    else {print "not ok 1\n"}
if ($result =~ /expected-but-not-there/i) { print "ok 2\n" } 
    else {print "not ok 2\n"}
if ($result ne "only the good stuff") { print "not " }
print "ok 3\n";
 
print "Anything that makes sense at the time\n"; 

Makefile
    This allows you to use the command make test and have the right th
+ing happen.

test:
    perl tst.pl

make test
    This is the output from make test.

perl tst.pl
t/tst1..............ok
t/tst2..............ok
t/tst3..............FAILED tests 2-3
    Failed 2/2 tests, 0.00% okay
Failed Test  Status Wstat Total Fail  Failed  List of failed
----------------------------------------------------------------------
+---------
t/tst3.t                      2    2 100.00%  2-3
Failed 1/3 test scripts, 66.67% okay. 1/6 subtests failed, 83.33% okay
+.
make: *** [test] Error 29

Fixing the @INC Path
Sometimes a test may have trouble loading the module that you are tryi
+ng to test. To fix it, add this code to the tests, for example in t/t
+st1.t.

use FindBin;
use lib "$FindBin::Bin/..";

This has the effect of adding the relative path ".." to the INC variab
+le at compile time. You might hope that the code use lib ".."; would 
+work, but it doesn't. Ordinary use lib "/path/to/my/file"; commands a
+dd to the INC path properly, but can't handle relative paths.
Conclusion
You can learn to enjoy the benefits of developing tests concurrently w
+ith your code. If you create a new test for bugs that you or others f
+ind, you are really doing great work!
[download]