G'day stevieb,
It's your module and you can test it in whatever way you want;
however, I'd have a problem with the separation of the eval block and $@ several lines later.
Here's a real-world ($work) example I wrote a few years ago that similarly tests for failure.
In this instance, it checks that an abstract class can't be instantiated.
I just grabbed it from git and only changed the class name to Abstract::Work::Class;
otherwise, this is a verbatim copy of 01-abstract.t:
#!perl -T
use 5.016;
use warnings;
use Test::More tests => 3;
use Abstract::Work::Class;
my $obj;
my $no_instantiation = 0;
my $eval_message = '';
eval {
$obj = Abstract::Work::Class::->new();
1;
} or do {
$eval_message = $@;
$no_instantiation = 1;
};
ok(! defined($obj), 'Test potential object remains undefined');
ok($no_instantiation, 'Test no instantiation of abstract class');
ok(index($eval_message, 'FATAL! Attempt to instantiate an abstract cla
+ss.') == 0,
'Test error message from attempting instantiation of abstract clas
+s');
I normally attempt to capture the value of $@ as the first statement in '... or do { ... };'.
As a testament to the robustness of that code,
it's from one of the core modules of a large 30+ module framework.
The framework has been modified, extended and enhanced many times, and built on many platforms, over the last four years;
01-abstract.t was last modified in May 2018.
It's a solid solution and you're welcome to adapt it to your needs if you want.
|