chrestomanci has asked for the wisdom of the Perl Monks concerning the following question:

Greetings wise brothers.

I am looking to develop a simple mod_perl application that will eventually run under Apache2, however I would like to develop the logic and flow of my application first without the complexity of running it inside Apache. I would also like to use the perl debugger to step from the test script into my mod_perl application.

I was hoping to develop the application via test driven development, so I could write something like:

use strict; use warnings; use Test::Most tests => 4; use Test::Apache::ModPerl::Test::Harness; # No such module use_ok('MyServer'); my $testHarness = Test::Apache::ModPerl::Test::Harness->new(); my $result = $testHarness->request('/hello/world'); is($result->response, 200, 'Response was success'); is($result->headers->{'some-header'}, 'magic', 'Magic header returned' +); is($result->body, 'Hello world', 'Expected body returned'); done_testing(4);

Unfortunately, I can't find a test harness that will allow me to test as I have described above. This surprises me as I have done similar testing in the past with Catalyst::Test and it has worked very nicely.

I first investigated Apache2::FakeRequest, and found that while it can create working mock requests, the response body does not get captured, but goes to stdout. The headers appear to go missing entirely.

I also investigated Test::Apache2. Version 2.05 would not build on my Linux box (Ubuntu Oneiric, x86_64), Version 2.04 did build and install, but then broke when my test application called $r->content_type('text/plain'), which is straight from the mod_perl fast start documentation.

I took a look at Apache::Test, but it looks complex to setup, and it is not clear if it is possible to use the perl debugger in any useful way. I also considered not using and mod_perl specific test harness and just using LWP in my test script, and point it to the real web server, but again there would be no way to use the perl debugger.

Am I missing something, or is there realy no simple way to test a mod_perl application?

Replies are listed 'Best First'.
Re: Apache mod_perl: Test driven developent?
by chromatic (Archbishop) on Jul 17, 2012 at 17:05 UTC

    Is your application tied to the internals of mod_perl, or is mod_perl merely a deployment concern?

    If the latter, you can write it to conform to PSGI with Plack or a compatible mechanism and test it with something like Test::WWW::Mechanize::PSGI.

      Thank you for your advice.

      My application is new and is not tied to mod_perl. The reason I am looking to develop with mod_perl, is because the application is very simple, but I want maximum performance, and minimal dependencies.

      I am aware of frameworks such as Catalyst and Dancer, and I have used them in the past to create fancy web sites, but for this project I am looking to create a simple file server that serves files from disc over http. If it where any simpler, I could have done the whole thing using only Apache configuration, mod_rewrite etc, but I need a small amount of logic to serve some files on the fly that don't actually exist on disc, and divert some requests to different URLs based on the client.

      Based on your advice, I took a look at Plack, and it does look feasible, lightweight, and testable. Also, I can install all the dependences via Ubuntu packages, which will simplify deployment.

Re: Apache mod_perl: Test driven developent?
by sundialsvc4 (Abbot) on Jul 17, 2012 at 19:53 UTC

    I definitely agree with the notion of using Plack, instead of mod_perl.   I frankly don’t believe that it is necessary any more to embed a Perl interpreter environment into an Apache worker-process.   When you relegate the Apache processes to the role of sending a request to an external worker and receiving the result therefrom, it now becomes possible for any PSGI compatible mechanism, including the plackup command-line program, to take its place.   The Apache processes themselves remain as they should be:   lean, mean, and small.   It is now significantly easier to test the web software.