Ali.as

Testing Perl Code

Perl modules and even sometimes applications are best shipped with automatic test scripts. These are designed to ensure that no errors occur when the modules are changed later. Especially in Perl there is a big culture around testing. This is reflected in the CPAN Testers system, which is also well integrated into CPAN. Participants in this provide machines that automatically test Perl modules and make the results of the test scripts available on the Internet.

For test scripts to be effective, they must cover the entire functionality of the program. How to write suitable software tests is not to be covered in this book (information on this can be found, for example, in Wikipedia: w:Softwaretest). Rather, the methods that Perl provides to the programmer for software testing will be described here.

Concept

Test scripts are rarely executed manually. This task is given to a test driver, which calls the test scripts automatically and evaluates the results. In case of errors or discrepancies, the user is informed and (depending on the driver, in varying detail) information about the failed test is output.

Technically, test scripts communicate using a simple, line-based format. Nevertheless, the communication usually happens via specialized modules, which can then automatically output additional information in the event of an error.

Basically, a test script registers a certain number of tests to be executed and then reports success or failure for each test case. Each case can be provided with a descriptive text. The number of tests ensures that an error can be detected if a test script crashes prematurely.

Modules

Test::Simple

Probably the simplest test module is Test::Simple. It offers exactly one function: ok($condition, $description). If $condition is a true expression, the test passes, otherwise it does not. Test::Simple expects from the programmer the number of tests to be executed. This must be known beforehand and is written after the use line. Test programs display the text given as $description if the test fails, to make debugging easier. A suitable description could be: "module loads ok".

Test::More

For more sophisticated needs, Test::More is available. It provides numerous functions to cover common test cases. Test scripts previously created with Test::Simple will always run with Test::More, so an exchange of the use line is sufficient. For comparisons, it is often helpful to know what value was actually returned. However, the ok known from Test::Simple cannot know anything about this. For that there is is($actual_value, $expected_value, $description) and isnt. Complex data structures would normally entail a long chain of comparisons. A strong workaround is is_deeply: Like is, it compares the first two arguments, but as a data structure rather than just a scalar. (With is, the data structures would be converted to memory addresses, which are always different).

For module authors it is certainly interesting to check before all other tests whether the module can be loaded at all - if this is not the case, all further tests are pointless. For this purpose there is the function require_ok($module name), which does this in a simple and straightforward way. Alternatively, use_ok can be used, but such a call must then be made in a BEGIN block.

It may happen that some tests require additional software that is not installed everywhere. Often this software is not required to use the module, so it makes little sense to list this module as a dependency. Or certain tests cannot be executed under certain operating systems.

So that the tests do not have to be aborted with an error in this case, tests can be skipped if, for example, modules are not installed. This is done with the skip function. A descriptive text and the number of tests to skip are given as arguments.



Content copyright 2002 Ali.as
All rights reserved.