Testing scripts

Testing Scripts
Randal L. Schwartz, merlyn@stonehenge.com
Version LT-1.05 on 13 Jun 2012

This document is copyright 2012 by Randal L. Schwartz, Stonehenge Consulting Services, Inc.
This work is licensed under Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License
http://creativecommons.org/licenses/by-nc-sa/3.0/

Monday, June 25, 12 1

• Problem:
• Ya gotta test!
• Solution:
• use Test::More and friends
• But:
• What about scripts!


• Problem:
• scripts are separate process
• hard to mock things
• Solution:
• Don’t use a separate process
• Require your script in your .t
• But:
• How will I invoke it then?


• Problem:
• Loose code is effectively “main”
• Solution:
• Bundle loose code into a run subroutine:
sub run { ... }
• Also ensure true value at end of script
• But:
• What will invoke “run” then?


• Problem:
• Invoke “run” when run normally
• Don’t invoke “run” via require
• Solution:
• Use “caller”:
run(@ARGV) unless caller;
• But:
• What about namespace of .t ﬁle


• Problem:
• Collision between script and .t names
• Solution:
• Bring it into its own package:
BEGIN {
package Program;
require "your-script";
die $@ if $@;
}
• But:
• How to “invoke the program” from tests?


• Problem:
• Simulate execution
• Solution:
• Invoke run() with desired @ARGV:
subtest try_it => sub {
Program::run(qw(--foo --bar abc));
};
• But:
• What about exceptions, exit, stdout?


• Problem:
• Trapping everything (not just die)
• eval doesn’t cut it!
• Solution:
• Test::Trap!
use Test::Trap;
trap {
Program::run(qw(--foo --bar abc));
};
• But:
• How will I know how the code ﬁnished?


• Problem:
• Was it normal exit, “exit”, or die?
• Solution:
• examine $trap object after trap { .. }
ok $trap->exit, 0, "exited 0";
like $trap->die, qr{missing args};
• But:
• What about stdout, stderr, warnings?


• Problem:
• What about those outputs?
• Solution:
• Test::Trap captures those too!
like $trap->stdout, qr{usage};
is $trap->stderr, q{}, "quiet errors";
is @{$trap->warn}, 1, "exactly 1 warn";
• But:
• What about stubbing or mocking?


• Problem:
• Want to override some behavior
• Solution:
• Monkey patching!
subtest stub_it => sub {
local *Program::some_sub = sub { ... };
trap { Program::run() };
};
• But:
• What about stdin?


• Problem:
• Provide stdin for script
• Solution:
• Small matter of programming:
local *STDIN;
open STDIN, "<", (my $S = join(q{}));
$$S .= "onentwonthreen";
trap { ... };
$$S .= "fournﬁven"; trap { ... };
• But:
• What about chdir?


• Problem:
• chdir has global effect
• Solution:
• Test::Trap is pluggable!
use Test::Trap::mine qw(:cwd);
trap { chdir "/tmp"; Program::run() };
• See my blog, or might be core now
• But:
• Does this really work for all scripts


• Problem:
• Script might need complex interaction
• Maybe can’t edit code into run()
• Code might fork
• Solution:
• Yeah, traditional subprocesses
• Perhaps combined with Expect
• But:
• Test::Trap is amazingly useful!


Follow me

• Twitter: @merlyn
• G+: Randal L. Schwartz
• Personal blog: merlyn.posterous.com
• http://blogs.perl.org/users/randal_l_schwartz/
• merlyn, realmerlyn, or RandalSchwartz


Testing scripts

More Related Content

Similar to Testing scripts (20)

More from Randal Schwartz (10)

Recently uploaded (20)

Testing scripts