Re: Re: Starting the development of a module : thoughts

[Masem]

What goes into tests is easy: this is the same concept as unit testing for object-oriented languages (C++ and Java). Basically you want to test every 'reasonable' object and function to make sure they work in every 'reasonable' test case that you can think of. While this can be a pain to add after your main program is said and done, the concept of unit testing is that these types of short codebits would be developed while you are developing the classes and functions, so inclusion into the test portions is trivial. Tests should basically make sure you are getting expected results from functions and code, such as:

sub add { my ($a,$b) = @_; return $a+$b; }

# Test code:
print "not ok" if add(2,2) != 4;

Now, what you actually print out is still a bit of a quandry for me; I know that there's info about it (that I happened upon luckily) at perldoc Test and perldoc Test::Harness. From my understanding (please correct me) is that the testing process sits at the end of STDOUT and intercepts everything. The first thing that the test scripts (as a whole) must print out is a "1..N\n" string, indicating the number of tests (=N). Each test then should print out "ok M\n" or "not ok M\n", where M is the specific test number. The test code runs all tests regardless of failures of previous ones, and reports the fraction of tests that failed at the end of the test cycle. When you install from CPAN, you'll see those test modules in action.

And again, from the docs and other module examples, you either want one full, comprehensive test in the ./test.pl file, or several small test files in ./t/*.t. In the latter case, tests are run in sorted order, which is why many people name files like "01test.t" as to have the specific tests executed in a logical order while still having the name printed out when CPAN-installing.

---

Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain