Bulletproofing the Mojolicious test suite

I spend some time with the client. Although I wrote some tests for it, his test suite needs more love in the future. But don’t worry, I’m still there. ;)

In some situations it could happen that a server creates an infinite redirect loop. User agents are supposed to detect them. Firefox for example displays a message after about 30 redirects, the curl of my mentor allows 50 redirects of this:

get '/redirect_endless' => sub {
    my $self = shift;
    $self->redirect_to('redirect_endless');
} => 'redirect_endless';

The Mojo::Client ATM doesn’t detect this at all, so this test fails:

my $max_endless_redirects = 500;
$client->max_redirects($max_endless_redirects);
$tx         = $client->get('/redirect_endless');
my $counter = 0;
$counter++ while $tx = $tx->previous;
isnt($counter, $max_endless_redirects, 'endless redirect detected');

I’m not sure if this is a problem, since one needs to increase the client’s max_redirects value explicitely. But maybe it’s not too hard to detect if a redirect comes in the 30st time. In addition, it’s only a SHOULD.

Sometimes there’s a MUST in RFC 2616, like here:

All responses to the HEAD request method MUST NOT include a message-body […]. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body.

In Mojolicious it’s easy to write actions which respond with 204 or 304 statuus and a body. We think the framework user should not be allowed to break its RFC 2616 compliance, so I wrote tests for this situation.