Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: perl script testing

by pemungkah (Priest)
on Dec 10, 2013 at 01:38 UTC ( #1066357=note: print w/replies, xml ) Need Help??

in reply to perl script testing

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;
This setup allows you to create 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 from the command line, which will cause it to call the run() routine and thereby execute the package as a script.

Replies are listed 'Best First'.
Re^2: perl script testing
by pradeep.cbp (Novice) on Dec 10, 2013 at 06:47 UTC
    Thanks for the solution I think 2nd method which you told is suitable to test my scripts.
    I am new for testing and can you please explain what is "# Main routine here" and "... rest of implementation here..." and "__PACKAGE__->run() unless caller();"

    you have told to "write tests for the subs in it" what it means?????
      This is a skeleton of your application to be:
      package MyCode; use strict; use warnings; sub run { # Main routine here } ... rest of implementation here... __PACKAGE__->run() unless caller(); 1;
      The "Main program here" section is going to be the code that basically reads the command line options, figures out what to do, and then calls the other subs or methods to make it happen. The "rest of implementation here" is simply placeholder text to indicate where you'd put the code that actually implements getting things done - that is the code your tests would be testing. The "__PACKAGE__..." line is what makes this .pm file into an executable program; it says "if caller() doesn' return anything (that is, we haven't been loaded by someone else as a module), execute this package's run() method."

      Here's a contrived example.

      package Sample; use strict; use warnings; use GetOpt::Long; __PACKAGE__->run() unless caller(); sub run { my($should_foo); die "usage: [--foo|--bar]\n" unless(GetOptions('foo' => \$should_foo, 'bar' => \$should_bar); my $value = $should_foo ? foo() : bar(); print $value; } sub foo { return "Foo to you too\n"; } sub bar { return "The best bar none\n"; } 1;
      Now in you tests, you can do stuff like this:
      use Test::More tests=>1; use Test::Exception; use Sample; is Sample->bar(), "The best bar none\n", 'bar() works'; is Sample->foo(), "Foo to you too\n", 'foo() works'; local @ARGV; # now undef dies_ok { Sample->run() } 'no args dies as expected'; like $@, qr/^usage:/, 'got a usage message';
      (Note that I have not tested this; it is simply meant to be an illustration of technique.)

      You package has subs that can be tested now to see if they do what they are supposed to. I hope this points you toward a workable direction.

      Edit: Not sure why this is getting down voted - would someone care to comment? Do you disagree with the technique? Do you feel I should have solved the problem more completely? Actual feedback is more useful.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1066357]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (3)
As of 2023-03-28 20:52 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (69 votes). Check out past polls.