3. Unit Tests
Benefits
● Find problems earlier
● Facilitate code changes
○ Help ensure changes did not affect other behavior
● Makes integration testing easier
● Code becomes “self documenting”
○ Just look at the tests
4. Unit Tests
Reality
● They do not “prove” software is correct
● They can be
○ wrong
○ hard to set up
● They do
○ increase programmer confidence
○ need to be treated like “real code”
5. Perl Testing
What is test code?
It’s just Perl code:
#!/usr/bin/perl -w
print "1..1n";
print 1 + 1 == 2 ? "ok 1n" : "not ok 1n";
Since 1 + 1 is 2, it prints:
1..1
ok 1
7. Perl Testing
Writing that kind of code would get tedious.
So, start with Test::Simple:
#!/usr/bin/perl -w
use Test::Simple tests => 1;
ok( 1 + 1 == 2 );
That runs the same test as before.
8. Perl Testing
Want more tests?
#!/usr/bin/perl -w
use Test::Simple tests => 2;
ok( 1 + 1 == 2 );
ok( 2 + 2 == 5 );
Run the test:
perl simple.t
Produces:
1..2
ok 1
not ok 2
#
Failed test (test.pl at line 5)
# Looks like you failed 1 tests of 2.
9. Perl Testing
Before we go on:
a few conventions
● Test files are kept in folders called ‘t’
● Test files are named <something>.t
○ 00-<test prerequisites>.t
○ 10-<module name>.t
○ 20-<module name>.t
There aren’t “rules”, it’s Perl!!
10. Perl Testing
Test::Simple
● Only provides ok()
● Can be awkward
○ Can’t tell what you got for a result
○ Only True/False (ok/not ok)
There is hope...