There are a large number of tools available which can be used to improve the quality of a perl module. This might mean decreasing the number of bugs in it, improving it's performance, improving it's ability to interact with various other perl tools, or making it more usable to others.

Below is a list of tools that are available which may help improve various aspects of your module. Not all will be useful in all situations, but it should still be a useful starting point.

Change Kwalitee
Every module should come with a description of the changes made with each version. There is a standard format that can be used. This site can be used to determine if your changes file meets the standard.
CPAN Testers
Once a module is released to CPAN, it is automatically tested by a set of volunteer testers on various platforms with different versions of perl. This site lists the platforms used to test the module as well as which ones succeed and which fail.
CPANTS Kwalitee
There are a number of best practices when creating a module. This site lists many of the most common ones and reports on which ones a module passes and which ones it fails.
These can be used to make sure that every line in your module is covered by at least one test in the test suite.
This is THE tool for profiling a module to see where the time is being spent in order to speed things up.
This can be used to check perl code to see whether it uses the best practices described in Damian Conway's Perl Best Practices book.
This can be used to fix indentation and enforce a few other coding style practices.
A spell checker for Pod files.
A check list of things to look at when releasing a new module.
A list of recommended perl modules. Especially useful are Task::Kensho::ModuleDev and Task::Kensho::Testing which contain modules recommended for development and testing.
Test::Pod, Test::Pod::Coverage
These are used to make sure that no pod files are missing and that they cover all of the functions in a module.
Travis CI
This tool can be used for modules stored on GitHUB. Every time a set of changes is checked in, the module will be automatically tested using a number of different perl versions to make sure that all tests pass.
  • Comment on Tools that may improve the overall quality of a module

Replies are listed 'Best First'.
Re: Tools that may improve the overall quality of a module
by davido (Cardinal) on Aug 18, 2015 at 23:17 UTC

    Seems like we looked at this list last week too.

    There are also some other testing modules, which probably deserve a thread of their own:

    Probably each of these exist because their author was bitten by a bug or a pet peeve a few too many times, was lazy enough to not want to get slowed down by being bitten again, impatient enough to develop a solution, and hubristic enough to release it for us to use. I don't use most of them, but can see where many of them could be useful for spotting problems I've bumped into here and there over the years. And I probably ought to employ more of them.

    But it is very important to note that these tests do not need to, and probably should never run on an end user's system. These are developer tools; they do nothing for proving the reliability of the module's target code. They simply help to ensure that the distribution is clean, and ready to release from a structural standpoint. It would be wrong to add them as dependencies to a distribution, and it would be wrong to slow down a test run by making them run on end user systems. Base their execution on two things: First, is an environment variable such as RELEASE_TESTING set? Second, are the dependencies available? If so, then run the tests. Otherwise, don't.