Over the past two years, I’ve gotten back into playing Dungeons & Dragons, the famous tabletop fantasy role-playing game. As a software developer and musician, one of my favorite character classes to play is the bard, a magical and inspiring performer or wordsmith. The list of basic bardic spells includes Vicious Mockery, enchanting verbal barbs that have the power to psychically damage and disadvantage an opponent even if they don’t understand the words. (Can you see why this is so appealing to a coder?)
Mocking has a role to play in software testing as well, in the form of mock objectsthat simulate parts of a system that are too brittle, too slow, too complicated, or otherwise too finicky to use in reality. They enable discrete unit testingwithout relying on dependencies external to the code being tested. Mocks are great for databases, web services, or other network resources where the goal is to test what you wrote, not what’s out in “the cloud” somewhere.
Speaking of web services and mocking, one of my favorites is the long-running FOAAS(link has language not safe for work), a surprisingly expansive RESTfulinsult service. There’s a corresponding Perl client API, of course, but what I was missing was a handy Perl script to call that API from the terminal command line. So I wrote the following over Thanksgivingbreak, trying to keep it simple while also showing the basics of mocking such an API. It also demonstrates some newer Perl syntax and testing techniques as well as brian d foy’s modulinoconcept from Mastering Perl(second edition, 2014)that marries script and module into a self-contained executable library.
#!/usr/bin/env perl
package Local::CallFOAAS; # this is a modulino
use Test2::V0; # enables strict, warnings, utf8
# declare all the new stuff we're using
use feature qw(say state);
use experimental qw(isa postderef signatures);
use Feature::Compat::Try;
use Syntax::Construct qw(non-destructive-substitution);
use WebService::FOAAS ();
use Package::Stash;
use Exception::Class (
NoMethodException => {
alias => 'throw_no_method',
fields => 'method',
},
ServiceException => { alias => 'throw_service' },
);
my $foaas = Package::Stash->new('WebService::FOAAS');
my $run_as =
!!$ENV{CPANTEST} ? 'test'
: !defined scalar caller ? 'run'
: undef;
__PACKAGE__->$run_as(@ARGV) if defined $run_as;
sub run ( $class, @args ) {
try { say $class->call_method(@args) }
catch ($e) {
die 'No method ', $e->method, "\n"
if $e isa NoMethodException;
die 'Service error: ', $e->error, "\n"
if $e isa ServiceException;
die "$e\n";
}
return;
}
# Utilities
sub methods ($) {
state @methods = sort map s/^foaas_(.+)/$1/r,
grep /^foaas_/, $foaas->list_all_symbols('CODE');
return @methods;
}
sub call_method ( $class, $method = '', @args ) {
state %methods = map { $_ => 1 } $class->methods();
throw_no_method( method => $method )
unless $methods{$method};
return do {
try { $foaas->get_symbol("&$method")->(@args) }
catch ($e) { throw_service( error => $e ) }
};
}
# Testing
sub test ( $class, @ ) {
state $stash = Package::Stash->new($class);
state @tests = sort grep /^_test_/,
$stash->list_all_symbols('CODE');
for my $test (@tests) {
subtest $test => sub {
try { $class->$test() }
catch ($e) { diag $e }
};
}
done_testing();
return;
}
sub _test_can ($class) {
state @subs = qw(run call_method methods test);
can_ok( $class, \@subs, "can do: @subs" );
return;
}
sub _test_methods ($class) {
my $mock = mock 'WebService::FOAAS' => ( track => 1 );
for my $method ( $class->methods() ) {
$mock->override( $method => 1 );
ok lives { $class->call_method($method) },
"$method lives";
ok scalar $mock->sub_tracking->{$method}->@*,
"$method called";
}
return;
}
sub _test_service_failure ($class) {
my $mock = mock 'WebService::FOAAS';
for my $method ( $class->methods() ) {
$mock->override( $method => sub { die 'mocked' } );
my $exception =
dies { $class->call_method($method) };
isa_ok $exception, ['ServiceException'],
"$method throws ServiceException on failure";
like $exception->error, qr/^mocked/,
"correct error in $method exception";
}
return;
}
1;
Let’s walk through the code above.
Preliminaries
First, there’s a generic shebang lineto indicate that Unix and Linux systems should use the perlexecutable found in the user’s PATH via the envcommand. I declare a package name (in the Local:: namespace) so as not to pollute the default mainpackage of other scripts that might want to requirethis as a module. Then I use the Test2::V0 bundlefrom Test2::Suitesince the embedded testing code uses many of its functions. This also has the side effect of enabling the strict, warnings, and utf8pragmas, so there’s no need to explicitly usethem here.
(Why Test2instead of Test::Moreand its derivatives and add-ons? Both are maintained by the same author, who recommends the former. I’m seeing more and more modules using it, so I thought this would be a great opportunity to learn.)
I then declare all the new-ish Perl features I’d like to use that need to be explicitly enabled so as not to sacrifice backward compatibilitywith older versions of Perl 5. As of this writing, some of these features (the isaclass instance operator, named argument subroutine signatures, and try/catchexception handlingsyntax) are considered experimental, with the latter enabled in older versions of Perl via the Feature::Compat::Trymodule. The friendlier postfix dereferencingsyntax was mainlined in Perl version 5.24, but versions 5.20 and 5.22 still need it experimental. Finally, I use Syntax::Constructto announce the /rflag for non-destructive regular expression text substitutions introduced in version 5.14.
Next, I bring in the aforementioned FOAAS Perl API without importing any of its functions, Package::Stashto make metaprogrammingeasier, and a couple of exception classesso that the command line function and other consumers might better tell what caused a failure. In preparation for the methods below dynamically discovering what functions are provided by WebService::FOAAS, I gather upits symbol table (or stash) into the $foaasvariable.
The next block determines how, if at all, I’m going to run the code as a script. If the CPANTESTenvironment variable is set, I’ll call the testclass method sub, but if there’s no subroutine callingme I’ll execute the runclass method. Either will receive the command line arguments from @ARGV. If neither of these conditions is true, do nothing; the rest of the code is method declarations.
Modulino methods, metaprogramming, and exceptions
The first of these is the runmethod. It’s a thin wrapper around the call_methodclass method detailed below, either outputting its result or dieing with an appropriate error depending on the class of exception thrown. Although I chose not to write tests for this output, future tests might call this method and catch these rethrown exceptions to match against them. The messages end with a \nnewline character so dieknows not to append the current script line number.
Next is a utility method called methodsthat uses Package::Stash’s list_all_symbolsto retrieve the names of all named CODEblocks (i.e., subs) from WebService::FOAAS’s symbol table. Reading from right to left, these are then filtered with grepto only find those beginning in foaas_and then transformed with mapto remove that prefix. The list is then sorted and stored in a statevariable and returned so it need not be initialized again.
(As an aside, although perlcriticsternly warns against it I’ve chosen the expression forms of grepand maphere over their block formsfor simplicity’s sake. It’s OK to bend the rulesif you have a good reason.)
sub call_methodis where the real action takes place. Its parameters are the class that called it, the name of a FOAAS $method(defaulted to the empty string), and an array of optional arguments in @args. I build a hash or associative array from the earlier methodsmethod which I then use to see if the passed method name is one I know about. If not, I throw a NoMethodExceptionusing the throw_no_methodalias function created when I used Exception::Classat the beginning. Using a function instead of NoMethodException->throw()means that it’s checked at compile time rather than runtime, catching typos.
I get the subroutine (denoted by a &sigil) named by $methodfrom the $foaasstash and pass it any further received arguments from @args. If that WebService::FOAAS subroutine throws an exception it’ll be caught and re-thrown as a ServiceException; otherwise call_methodreturns the result. It’s up to the caller to determine what, if anything, to do with that result or any thrown exceptions.
Testing the modulino with mocks
This is where I start using those Test2::Suite toolsI mentioned at the beginning. The testclass method starts by building a filtered list of all subs beginning with _test_in the current class, much like methodsdid above with WebService::FOAAS. I then loop through that list of subs, running each as a subtestcontaining a class method with any exceptions reported as diagnostics.
The rest of the modulino is subtest methods, starting with a simple _test_cansanity check for the public methods in the class. Following that is _test_methods, which starts by mocking the WebService::FOAAS package and telling Test2::Mock I want to trackany added, overridden, or set subs. I then loop through all the method names returned by the methodsclass method, overrideing each one to return a simple true value. I then test passing those names to call_methodand use the hash reference returned by sub_trackingto check that the overridden subwas called. This seems a lot simpler than the Test::Builder-based mocking libraries I’ve tried like Test::MockModuleand Test::MockObject.
_test_service_failureacts in much the same way, checking that call_methodcorrectly throws ServiceExceptions if the wrapped WebService::FOAAS function dies. The main difference is that the mocked WebService::FOAAS subs are now overridden with a code reference (sub { die 'mocked' }), which call_methoduses to populate the rethrown ServiceException’s errorfield.
Wrapping up
With luck, this article has given you some ideas, whether it’s in making scripts (perhaps legacy code) testable to improve them, or writing better unit tests that mock dependencies, or delving a little into metaprogramming so you can dynamically support and test new features of said dependencies. I hope you haven’t come away too offended, at least. Let me know in the comments what you think.


Comments
2 responses to “Vicious (test) mockery of a Perl modulino”
[…] Vicious (test) mockery of a Perl modulino […]
[…] ← Vicious (test) mockery of a Perl modulino […]