There are generally speaking two different ways to test command-line scripts. One, run the script and verify that the script both prints the output expected (on STDOUT and STDERR) and does what you expected it to do (update files, move things, whatever). The other is to build the script in such a way you can unit-test the code without running the whole script.

The first one can generally be done with IPC::Open3 and Test::Differences; if your script has side effects (file deleted, code checked in to an SCM, etc.), you'll need to use something like Test::More or Test::Unit or Test::Routine to verify the side effects happened. It may be necessary to get a little creative with the side effects tests; for instance, you probably don't want your tests checking code into your central SCM repo, so making the repo configurable is a good idea.

The second one may actually end up being easier to test. This pattern can be useful (cribbed from How a script becomes a module):

package MyCode;
use strict;
use warnings;

sub run {
    # Main routine here
}

... rest of implementation here...

__PACKAGE__->run() unless caller();
1;
[download]

This setup allows you to create MyCode.pm and then either use MyCode and write tests (using one of the Test:: packages listed above) for the subs/methods in it, or to simply run MyCode.pm from the command line, which will cause it to call the run() routine and thereby execute the package as a script.