A new must use module - Test::Exception

I write quite a few unit tests that have methods or subs that throw exceptions (like most good code should... this rule has numerous good exceptions! hahaha, sorry couldn't resist.). A few months ago I ran across Test::Exception.

In the past I would often write unit tests for these cases like:
{
my $err;
my $obj;

eval { $obj = MyObject->new; };

## constructor expected to fail
$err = $@;
ok $err, "constructor - missing parameters";

## or for methods that aren't suppose to throw
eval { $obj = MyObject->new( server => 'localhost' ) };

## check constructor
$err = $@;
ok !$err, "constructor";
isa_ok $obj, 'MyObject';
}
This construct became very tiring, verbose and distracts from what is really going on. (Yuck!)

With Test::Exception, I can convert these annoying eval blocks into nicely contain lines.

Example from above:
use Test::Exception;

{
my $obj;

throws_ok { $obj = MyObject->new; } qr/Error Message to match/,
    'constructor - missing parameters';

lives_ok { $obj = MyObject->new( server => 'localhost' ) } "constructor";
isa_ok $obj, 'MyObject';
}
The only thing that is a bit of a syntax gotcha is that the lives_ok requires a parameters of 'block "string"'. Notice that missing comma, odd but it is much better than my previous eval crap.

Test::Exception really makes this better, thanks to the author.

Comments

  1. AnonymousFebruary 24, 2011 at 5:17 AM

    May be you will be interested in my blog entry about testing - http://blogs.perl.org/users/alexey_shrub/2011/02/non-functional-perl-code-testing---automated-code-review.html

    ReplyDelete

Post a Comment

Popular posts from this blog

Template Toolkit Debugging inside of Perl Dancer

The other day someone was asking how to enable Template Toolkit debugging inside of Perl Dancer in the #dancer IRC channel, it seemed like a good time for a write up. The template engine configuration directive supports passing through various options like start_tag and stop_tag as explained in Dancer::Template::TemplateToolkit POD. And alludes to being able to pass other options. How To pass TT options like those found in Template::Constants , there must be a DEBUG section in engines -> template_toolkit , usually found in config.yml . Example Snippet Here is an example: A few notes Remove leading DEBUG_ from TT constants. The option DEBUG_PLUGINS becomes plugins . Multiple options can be separated with a comma. Example: DEBUG: "provider,plugins" . Be warned, some of these options can lead to tons of information :) __END__
Read more

BootstrapX clickover

Birth The last few weeks, i've been pushing Bootstrap in various directions. Most of the time, its being hacking around Popovers. Our current design uses Popovers with forms. It provides a very nice balance between in page action and more subtle interruption to viewing the page than a modal. Over the last few weeks, I've found a few quirks with using Popover's trigger action of 'focus'. This works fine with forms but on Chrome and Safari 'focus' events are supported incompletely . In addition to that varied support we have a few other needs that inspired a new Bootstrap extension. BootstrapX - Clickover . Our requirements are: Click button/link/icon to toggle display of popover content Option to click 'away' from popover to close Ability to have 'popover' autoclose after some amount of time Option to have element inside of popover hide it I suspect, in the future, it will need to only auto close when user's mouse
Read more

Changing Dancer::Plugin::Ajax's content type

Dancer does lots of great things. It has a nice clean way to define routes to handle AJAX routes using the plugin Dancer::Plugin::Ajax . ajax routes are defined in a clear way: ajax '/stuff' => sub { # do work and return }; This plugin technique allows for clear way to separate between ajax and other types of actions for the same route. ajax '/stuff' => sub { # do ajax-y stuff here }; get '/stuff' => sub { # handle html response }; Unfortunately, the one negative with Dancer::Plugin::Ajax is that is assumes all responses will be XML. A quick fix is to manually set the content type in each ajax handler. ajax '/stuff' => sub { content_type('application/json'); # do work }; or add set it as a general option in your main before hook or in each prefix route handler like: package WebApp; hook before => sub { if ( request->is_ajax ) { content_type('application/json'); } };
Read more