I suppos I kind of do testing already by running my executing have finished code and looking to see if the results are as expected and maybe throwing in a warning if they aren't. Admittedly, this testing method is very crude, however, and not very reliable. Thanks for the advice.

You're half way there then. Instead of using a single script that you keep changing, once you get your 'test' to run, copy it to a file with a .t extension and that's it.

Of course, using Test::More is a good choice for doing the assertions. Here's the difference between a normal test script, and a real test:

use warnings;
use strict;

use My::Module;

my ($x, $y) = My::Module->pairs();

print "ok" if $x == $y;
[download]

test:

use warnings;
use strict;

use Test::More;

use_ok('My::Module');

my ($x, $y) = My::Module->pairs();

is ($x, $y, "pairs() returns a pair that match");

done_testing();
[download]

The latter will tell you exactly what was expected and what failed if there's a fail. The former doesn't. Not much extra effort. So if you're testing your code with one-offs, save them to test files instead, and now that part of your code will be tested every time you run your suite.

Example test output from above on fail:

ok 1 - use My::Module;
not ok 2 - pairs() returns a pair that match
#   Failed test 'pairs() returns a pair that match'
#   at pairs.t line 11.
#          got: '1'
#     expected: '2'
1..2
# Looks like you failed 1 test of 2.
[download]

...because someone made a typo in the pairs() function:

sub pairs {
    return (1, 2);
}
[download]

In addition to stevieb++'s posting:

Test scripts can do more: You feed your code not only with expected input and test for correct output. But you also feed your code with intentionally bad input and test for correct error handling.

"Intentionally bad input" can be something simple as a string passed to a function that expects a number, or some random garbage instead of a well-formed input file. Or, it can be a test for a known error in an older version.

For example, have a look at the tests that come bundled with DBD::ODBC:

• 01base.t to 90_trace_flags.t, odbc_describe_parameter.t, and sql_type_cast.t are "just" test for the API functions. Load the module, test that some functions basically work.
• pod-coverage.t and pod.t are "documentation tests", that check that everything is documented, and that the documentation itself is syntactically correct. Not much effort for the author, just load and call Test::Pod or Pod::Coverage and let them do their job.
• The most important tests are the rt_XXXX.t tests. They all test for known errors from the bug tracking system, making sure that the overall "make test" will fail if one of the known errors is accidentally reintroduced or "reinvented".

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)