I'm copying the contents into perlmonks in case the website disappears some day.
Update: For a followup... Is there a better way to get all the t/.t test files an array?.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!
In reply to Re: Testing for Beginners
by tphyahoo
in thread Testing for Beginners
by markmoon
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |