Actually, it often isn't particularly hard to test complete scripts.

Lately I've been refining an approach that lets me test scripts much more extensively. For example, I can test a script that makes modifications to the DB w/o having those modifications actually happen. A few of the test scenarios require following a few specific best practices that were already common for our scripts, mainly, writing scripts in a format like:

#!.../perl ...
use strict;
... load more modules ...

our $MAX_SECS = 60;
... more configuration 'constants' ...

Main( @ARGV )
    if  $0 eq __FILE__;
return 0;

sub ...
... more subs ...
[download]

Then I have a module that facilitates testing the script by, for example, having the test script load mocks, fork, set $0, load the script (which runs it). A common mock is one that allows full access to the DB except that 'commit' only pretends to happen and you can also load temporary fake data either on top of or in place of existing data on a table-by-table basis.

STDOUT and STDERR of the script get directed to temporary files so the test code can make assertions about what does or doesn't get output. And my module facilitates setting up what text the script should find if it reads STDIN.

Other scenarios include:

Load()

Reads in the code of the script, prepends "return 0;" and '# line 1 "$file"' then eval()s it. This allows the test script to then call subroutines in the script, including Main().

LoadAndInit()

Just don't set $0 then load the script so the globals get initialized and just Main() doesn't get called. This scenario is the one that requires the script under test to follow that best practice.

Spawn()

This forks then runs the script but doesn't wait. There is even a pipe between parent and child so the child can run both "before run" and "after run" code that can even exchange data with the parent. The "before run" code runs after the script is compiled so it can override initializations and mock other things that are harder to mock with the "before compile" code of the test script.

Yes, factor your code into modules that are easier to test. But having a bit of code that isn't factored into such doesn't mean it is that hard to test it, at least not in Perl.

And, yes, I sometimes write tests for code before I completely refactor the code. So I have to write tests for code that isn't perfectly factored.

Oh, also, the test scripts start with, for example, "package BinTest;" so they don't accidentally overwrite something in the script's main:: package.