|Do you know where your variables are?|
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.
In reply to Re: Tools that may improve the overall quality of a module