good chemistry is complicated,
and a little bit messy -LW
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:
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:
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.
In reply to Re: A brief question about testing/best practices (just do it)