http://qs1969.pair.com?node_id=1183300


in reply to Re: Using guards for script execution?
in thread Using guards for script execution?

Actually, there can be value to writing a script like:

#!/usr/bin/perl -w use strict; use Some::Module qw< this that >; my $Config = ...; Main( @ARGV ) if $0 eq __FILE__; return 0; # Exits -- no run-time code below this point, just 'sub's. sub Main { ... }

Because it allows you to write more types of tests for the code included in the script. An automated test can require or do the script in order to have the global configuration initialized (which should not involve any interesting calculations) and then the test can do some setup and then call subroutines (including Main) from the script. An automated test can even do some setup, set C<$0>, then require/do the script and it will execute normally (except for things set up by the test) and then return control to the test where aspects of the process can be checked.

Yes, you can also do even more work to move absolutely all of the code out of the script and into one or more modules and then do all of those types of tests using the module(s). Indeed, there can be even more benefits to moving all of the code to modules. But my experience is that very often this extra work is not warranted for at least some of the code in a script and the trivial work of allowing the script itself to be loaded without it always running is all that is needed to make complete automated testing possible.

- tye        

Replies are listed 'Best First'.
Re^3: Using guards for script execution? (testing)
by Anonymous Monk on Mar 01, 2017 at 17:58 UTC
    That is far too 20th century for my tastes. You should not test scripts, you should test interfaces. Your scripts really should just be stubs that call one method: run()

      “My tastes?” There is no “my” in anonymity. Whatever you are is devoid of tastes; taste.