Start of topic | Skip to actions

Useful Perl Testing Modules

This a relatively short list of Test modules that are available from CPAN. I picked some of the more powerful and useful modules that are available and that can easily be added to your distributions. These are not replacements for testing your module code but rather a supplement for the author.

Test::Distribution

From the Description

When using this module in a test script, it goes through all the modules in your distribution, checks their POD, checks that they compile ok and checks that they all define a $VERSION.

This module also performs a numer of test on the distribution itself. It checks that your files match your SIGNATURE file if you have one. It checks that your distribution isn't missing certain 'core' description files. It checks to see you havent' missed out listing any pre-requisites in Makefile.PL.

It defines its own testing plan, so you usually don't use it in conjunction with other Test::* modules in the same file. It's recommended that you just create a one-line test script as shown in the SYNOPSIS above. However, there are options...

This test bundle does a number of tests on your distribution. It includes Tests that are in some of the modules listed below ( Test::Pod, Test::Pod::Coverage, Test::Version). It is similiar to another module listed, Test::Kwalitee.

Test::Fixme

From the Description

When coding it is common to come up against problems that need to be addressed but that are not a big deal at the moment. What generally happens is that the coder adds comments like:

# FIXME - what about windows that are bigger than the screen?

# FIXME - add checking of user priviledges here.

Test::Fixme allows you to add a test file that ensures that none of these get forgotten in the module

This allows you to put in comments in your code and then go back and check to make sure you did not forget anything before you distribute your module. Test::Fixme is not limited to just FIXME but can be changed to look for any KEYWORD in that you it to look for in your comments. for example, I like to use the keyword TODO in my code.

Test::Kwalitee

From the Description

Kwalitee is an automatically-measurable gauge of how good your software is. That's very different from quality, which a computer really can't measure in a general sense. (If you can, you've solved a hard problem in computer science.)

Kwalitee checks to see what files you have in your distribution to see if you pass its tests. Any/all the options can be turned off if you don't feel you need them.

Some of the things Kwalitee checks for are Changes file, Readme file, MANIFEST file, Build.PL file, etc... Kwalitee provides tests check that you have standard files that are used in most distributions. If you accidentally forget or delete something it will tell you.

Note: Currently unavailable on Windows due to problems with Kwalitee modules that it depends on.

Test::Inline

From the Description

Embedding tests allows tests to be placed near the code it's testing.

This is a nice supplement to the traditional .t files.

It's like XUnit, only better and Perl-style.

Test::Inline allows you to embed tests in your module using Pod. If you have a simple module it makes it easier to write your tests; it is right next to the code it is testing! I would not suggest that this be used in all cases but it can be useful.

Test::Nowarnings

From the Description

In general, your tests shouldn't produce warnings. This modules causes any warnings to be captured and stored. It automatically adds an extra test that will run when your script ends to check that there were no warnings. If there were any warings, the test will give a "not ok" and diagnostics of where, when and what the warning was, including a stack trace of what was going on when the it occurred.

No much to add here. This is always useful for making sure that your code is clean and does not do anything strange.

Test::Perl::Critic

From the Description

Perl::Critic is an extensible framework for creating and applying coding standards to Perl source code. Essentially, it is a static source code analysis engine.

For developing consistent programming standards and following best practices this module is for you. This parses your code and checks it against numerous pre-generate policies, code that does not comply with the policies will be returned as failed tests. The pre-generated policies are based on Perl Best Practices by Damain Conway. This does preclude you from disabling anything you disagree with or writing your policies that are appropriate your organization.

I find that this is very helpful (once I disable the policies I don't like) in ensuring that my code is consistent, even it is not always necessary. It also includes a check for VERSION information like Test::Version.

Test::Pod

From the Description

Check POD files for errors or warnings in a test file, using Pod::Simple to do the heavy lifting.

A mainstay for any developer, this checks your Pod, (you are writing Pod for your documentation, right?) and ensures that your syntax is correct.

Test::Pod::Coverage

From the Description (of Pod::Coverage)

Developers hate writing documentation. They'd hate it even more if their computer tattled on them, but maybe they'll be even more thankful in the long run. Even if not, perlmodstyle tells you to, so you must obey.

This module provides a mechanism for determining if the pod for a given module is comprehensive.

It expects to find either a =head(n>1) or an =item block documenting a subroutine.

Another good mainstay for developers, it checks to make sure that your methods in your module have some sort documentation. It is also highly configurable, so you can leave out specific method names that are not meant to be public interfaces.

Test::Spelling

From the Description

Check POD files for spelling mistakes, using Pod::Spell and spell to do the heavy lifting.

A good way of spell checking your Pod, I have also found it useful in that it forces your properly mark code inside of your documentation. It will try to identify sections that look like code and skip it, if it does not think it is code it will attempt to spell check it. If you clearly delimit code in your Pod using c< > then it will skip it.

Test::Strict

From the Description

The most basic test one can write is "does it compile ?". This module tests if the code compiles and play nice with Test::Simple modules.

Another good practice this module can test is to "use strict;" in all perl files.

By setting a minimum test coverage through all_cover_ok(), a code author can ensure his code is tested above a preset level of kwality throughout the development cycle.

Note: This check (if not this module) is also included in the Test::Perl::Critic module.

Test::Version

From the Description

Check files for VERSION information in perl modules.

Note: This check (if not this module) is also included in the Test::Perl::Critic module.

-- SteveKirkup - 28 Apr 2006

End of topic
Skip to actions | Back to top

RichmondPM