posted a horrible chunk of code to my blog. With all the scorn I threw about it there's one bit I didn't cover however, a sort of saving grace. The second line here:On Friday I
Devel::UseFromCommandLineOnly? What the heck is that, and why am I subclassing it? Well, that, boys and girls, is another quick module I knocked up while butchering the internals of Test::Builder. You see, I wrote Test::EnhancedIs as a proof of concept that I knew would very likely break just as soon as someone changed Test::Builder in the slightest. I'm offering it as unsupported experimental code, but even I know no sooner had I typed those warning words that someone else was busy typingpackage Test::EnhancedIs; use base qw(Devel::UseFromCommandLineOnly);
And committing it to their version control system. I know what'll happen next is that that person or their coworkers, months down the line when this inevitably breaks, will hunt me or the hardworking geniuses that maintain Test::Builder down to blame us for breaking their code. So I decided to not let that happen. If you run the above code it outputs:#!/usr/bin/perl use strict; use warnings; use Test::More tests => 1; use Test::EnhancedIs; # whooo, easier tests use Sharks; is(Sharks->armed,"frickin' laser beams");
Yep, that's Devel::UseFromTheCommandLineOnly kicking in and hitting you with the cluestick. However, if you remove line 7 from the above example and run the test loading the extra module from the command line like so:bash$ perl test.t 1..1 Invalid use of Test::EnhancedIs in 'test.t' at line 7; This module can only be loaded from the command line at test.t line 7
Everything is dandy. Devel::UserFromCommandLineOnly is on CPAN and GitHub if you want to play with it.travis-4:~ mark$ perl -MTest::EnhancedIs test.t 1..1 not ok 1 # Failed test at test.t line 9. # got: 'frickin' *sharp teeth' # expected: 'frickin' *laser beams' # Looks like you failed 1 test of 1.