How do I write a test to ensure that the module is loading the correct files if I don't yet know what the files in the directory will be?

You create a known set of files in the directory.

Let's assume a simple "pocket calculator module". Create - say three - files "one-plus-two.calc", "two-plus-three.calc", "three-times-five.calc", containing "1+2", "2+3", "3*5".

How do I test whether the module is performing these operations correctly?

You know the input (because you created it), you know the expected output. Compare the output of your module with the expected output. Test::More and friends are extremely useful.

Your test may either have a hardcoded result for each input file, perhaps in a hash (%expected=( "one-plus-two.calc" => 3, "two-plus-three.calc" => 5, ...)), or a result file for each input file ("one-plus-two.result" contains "3", and so on).

Do I need to create a bunch of dummy data structures that mimic all the different possibilities of what the real data will look like and run the tests with this dummy data?

If you want a 100% test, yes. Hint: You can generate the input and the expected output.

To test all basic operations on numbers from one to ten, use three nested loops:

my $testNo=1;
for my $x (1..10) {
  for my $y (1..10) {
    for my $op (qw( + - * / )) {
      write_file("test$testno.calc","$x $op $y");
      write_file("test$testno.result",eval "$x $op $y"); # eval just f
+or demo purposes ...
      $testNo++;
    }
  }
}
[download]

This seems like an awful lot of work and I'm not sure it would really be worth the time.

It depends on how the module is used, and how reliable it has to be. Start with a few simple tests, then extend.

If you find bugs later, FIRST add a test for the bug, THEN fix the bug, and re-run the tests to confirm that the bug is gone. This way, you will never re-introduce the bug, because the test for this bug will fail.

Another hint: Don't test the entire module at once, test its components (functions / methods). So if you have a file searching function (something like glob), write a test that runs that function on a set of files, and compare its return value with the expected result. ((You would expect it to return ( "one-plus-two.calc", "two-plus-three.calc", "three-times-five.calc" ) in the example.) You will likely have a function that parses a file. To test it, call it with a file with known content, and compare the return value with the expected result. (See above: %expected=( "one-plus-two.calc" => { op => '+', left => 1, right => 2 }, ... )). You will have a function that actually works on the parsed data. To test it, call it with known parser output. (use Test::More tests => 3; use Calculator; is(calculate({ op => '+', left => 1, right => 2 }),3,'add one plus two'); ...). You have a function that outputs data. To test it, call it with known input, as usual. (... is(numberToWords(12),"twelve","number to words for 12"); ...)

If your code does everything in one big function: Big chance to clean up your code! ;-) Like in the old unix philosopy, a function should do one thing, and it should do that right. As a rule of thumb, most functions should have drastically less than 100 lines of code.

Still confused? CPAN is full of tests. Look around how modules are tested. DBI and DBD::ODBC have a lots of tests, for every little detail. CGI has a few tests. HTML::Parser has some. Test::Simple has lots of tests, so does Text::CSV_XS. Most other modules come with at least a few tests. Pick a module you know well, and look at its tests.

Alexander