in reply to Guidelines for creating self-contained testable scripts

There are lots of ways to test things in Perl and ways for Perl to test other things too!

Another idea for you...

On my last Perl project which had a number of .pm modules (about 10 .pm files), I set each .pm file up with a standard test() subroutine whose name ('test') was not exported. Then also something like this: my $DEBUG =0; test() if $DEBUG;.

When I'm working with the module, adding functions or whatever, I set "my $DEBUG=1;" and my edit environment allows me to just hit a "run Perl" button and I run the code and see what happens. I add test cases to test() to get the module working. I don't try to call the subs in that .pm file from other programs until I have a good result from this module's test() function. So this .pm file looks like a .pl program with $DEBUG on.

To run all test subs in all modules, I just call FULL_PM_NAME::test() on each .pm file. Having some sort of naming convention can help. Maybe to test some shell scripts, you look in a directory and run the "program.test" executable of any executable "program" which has a corresponding "program.test", etc.

This is a simple strategy suited for small projects. When the project gets larger and test cases so complex that adding them all into the source .pm file doesn't make sense, then of course things change. But I think even in that situation a case could be made for including a "kick-the-tires", "smoke-test" into the .pm file.

I think testing is a broad subject and there is no "one size" fits all.