First of all, welcome to the wonderful world of testing! I recently started writing tests for my modules, and I'm hooked. :-)

References you might find helpful:

• Perl Testing: A Developer's Notebook, by Ian Langworth and chromatic (ISBN 0596100922)
• Kent Beck's Test-Driven Development (ISBN 0321146530)
• Andy Lester's presentation on automated testing

Relevant nodes found by Super Search (this is one of your best friends at Perl Monks):

• Testing: Fun for the family
• testing code
• Functional and Unit Test Redundancy
• What is the best way to add tests to existing code?
• Testing at the right granularity

Finally, don't forget to search CPAN:

• Devel::Cover
• Test::Tutorial
• Test::Simple
• Test::More
• ...and other members of the Test::* namespace

Your specific example of a function that checks bounds is certainly something that I would test. It will allow you to easily verify that it is behaving as expected (per the specifications), especially after you tweak the code (anything from a minor change to a complete refactoring).

For example: Does the function handle different types of input appropriately? What should happen if it is passed undef? An integer? A float? Does it work with positive and negative values? An alphanumeric string? A string that contains with special characters? The empty string? What other edge cases are there?

Just some initial thoughts. Hope this helps.

Yes, and to filter that a bit, I would start by reading the basics: Test::Simple (first) and Test::More (after).

Test::Tutorial, though temptingly named, is unfortunately only a placeholder.

It's true that I can't seem to find Test::Tutorial on CPAN any more, perhaps that is because it's part of the core Perl distribution since:

perldoc Test::Tutorial

works on the Linux boxes that I have access to.

As for how thorough you want to make your tests, that's up to you. If your bounds checking is essential to your module or you think it's likely to break, check it; otherwise skip it.

For testing random scripts, srand can be useful to make sure that rand will always return the same sequence while testing. You can also call the function you're testing several times, and make sure the results are consistent and not all the same.

For testing random scripts, srand can be useful to make sure that rand will always return the same sequence while testing. You can also call the function you're testing several times, and make sure the results are consistent and not all the same.

Calling the function repeatedly isn't a very robust test and using srand isn't a good idea because the underlying random number generator isn't the same across all platforms. I wrote Test::MockRandom specifically to help testing code that relies on random numbers. It overloads CORE::GLOBAL::rand to return a number from a user-specified list. This isolates the randomness from the algorithm that utilitizes the random number, allowing for robust testing.

As part of an article for The Perl Review last year, I wrote File::RandomLine as a simple example of how to use Test::MockRandom. Looking at the tests for that module might serve as a good "cookbook" tutorial.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

It helps if you think of your test suite as the most detailed specification for your modules. Any functionality your module is expected to deliver should be tested. Any failure condition your module can encounter should be tested to see whether the failure is handled correctly (for example does the module die when encountering an out-of-bounds value or does it return undef and log an error). The easiest way to do this is to write your tests for a given functionality before you write the implementation. Don't write a single line of code without first writing a test for it.

For the example you give, returning a random array element, off the top of my head I can think of the following tests:

• Is the returned value an element of the array.
• Is the array changed/unchanged after you have fetched the element(depending on your requirements)
• Is the index of the returned element properly random
• What happens if the function parameters are out of bounds
• What happens if the parameters are of an unsuitable type (string, floating point number)
• What happens if the function is called without parameters
• What happens if the array is empty

1) Does the element always fall within accepted bounds?
2) Is the distribution properly random?

Best thing to do is set up a wrapper to run your function some large x number of times, then store counts of each element number and print out the counts sorted by element number. This will show distribution and min / max. You can also calculate the average deviation from what would be the best possible distribution. For instance:

use strict;
use warnings;

my $min = 10;
my $max = 100;
my $tests = 10000;

my (%c, $n, $average, $deviations);

for (1..$tests) {
    $n = makerandom($min, $max);
    $c{$n}++;
}

$average = $tests / ($max - $min + 1);
for (sort {$a <=> $b} keys %c) {
    $n = $c{$_};
    $deviations += abs($n - $average);
    print "$_ => $n\n";
}
print "Average deviation +-" . $deviations / ($max - $min + 1) / $aver
+age * 100 . " % from $tests tests";

sub makerandom {
    my ($min, $max) = @_;
    return int rand ($max - $min + 1) + $min;
}
[download]

Average deviation +-6.9454945054945 % from 10000 tests
Average deviation +-2.24830769230769 % from 100000 tests
Average deviation +-0.77529010989011 % from 1000000 tests

You may want to check Test::RandomResults.