Your script is a front-end to the module you've written. You could move argument parsing into the module so that the binary (ie. script) *only* ever makes function/method calls to the module; the script does only its own basic logic. Then, the binary is irrelevant and you need not worry about testing it at all, less some compile checks.
pod2usage and other 'system' calls have their own tests written upon install, so you can almost certainly skip these. If you're that concerned, run a test to dump this output somewhere, then have a different, later test run POD and layout checks against the output of that sample file.
Anything that calls exit() can be caught with, like jcb said, a mock, or other forms of trickery (such as having a test file dump the output of a system call to an in-memory file, then check that). Note that you can run a script under system() and get actual return values.
Again, unless your script is a core part of your distribution (sounds like it isn't), make it as simple as possible. I might want to write my own because yours is too simple. Then, I can either use your publicized options() function/method, write my own for my own script, or utilize both yours append my own.
In the end, you don't really want to test the script anyways (where possible). You want to test what the script represents. The more you incorporate into the module(s), the less worry you have about testing the front-end script(s).
In reply to Re: Portably unit testing scripts
by stevieb
in thread Portably unit testing scripts
by wanna_code_perl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |