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 studying 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 have 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. Even 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 test 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 is correct. Test programs such as these can print all sorts of extra garbage. The harness just looks for a few regular expressions that show 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 thing 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 trying to test. To fix it, add this code to the tests, for example in t/tst1.t.

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

This has the effect of adding the relative path ".." to the INC variable 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 add to the INC path properly, but can't handle relative paths.
Conclusion
You can learn to enjoy the benefits of developing tests concurrently with your code. If you create a new test for bugs that you or others find, you are really doing great work!