Bulletproofing the Mojolicious test suite

Hi there,

the second week of my gsoc project is over. I started with verbosifying some Mojo tests (I think the Client test messages are much more readable now)… You’ll find verbose Mojo tests in the verbose_tests branch of my mojo fork. Damn, that client class is very flexible and awesome! Last night, Sebastian implemented a CSS3 selector type DOM parser, look at the hack of the day:

print Mojo::Client->new
        ->get('http://digg.com')->success
        ->dom->at('h3 a')->text;

I also tried to understand the Mojolicious dispatch process in detail. While playfully writing a simple but flexible content management plugin for Mojolicious, I saw one issue not for the first time: if you have a bridge with a callback (which is the standard method to do things in Mojolicious::Lite) and want to add some standard Mojolicious controller/action routes to that bridge, you’re in trouble, because the callback is merged together with the controller and action fields in the captures hash (see MojoX::Routes::Match) and when dispatching (see MojoX::Dispatcher::Routes), the callback wins, so the dispatcher gets the bridge callback twice.

I found absolutely no way to patch this without breaking anything else. I wrote a test for this situation, but it’s also possible that no one will ever need this, except me. For now, the workaround is to undef the cp thing:

# "Remote" action without callback
get '/' => {
    namespace   => 'Some',
    controller  => 'controller',
    action      => 'action',
    cb          => undef,
};

Oh, and I learned two things:

• the Perl debugger is great, sometimes
• debugging Mojolicious without proper breakpoints sucks