WWW::Mechanize has a module as part of the tests that implements a basic HTTP server. You could check out the test scripts there to see what its doing for some ideas.

However I know that running tests from a child doesn't work.

What problems have you come across? What you need to do is:

• disable test numbering
• disable headers/endings in the child processes

For example:

use strict;
use warnings;
use Test::More 'no_plan';

my $Num_children = 3;
my $Max_tests_per_child = 5;

my $Builder = Test::More->builder;
$Builder->use_numbers( 0 );

sub pass_and_pause {
    pass( "@_" );
    sleep rand( 5 );
};

foreach my $child ( 1 .. $Num_children ) {
    my $pid = fork;
    die "fork failed ($!)\n" unless defined $pid;
    if ( $pid ) {
        diag( "forking child $child" );
    } else {
        my $first_test = $Builder->current_test;
        $Builder->no_header;
        $Builder->no_ending;
        pass_and_pause( "child $child test $_" ) 
            for ( 1 .. 1 + rand( $Max_tests_per_child ) );
        exit $Builder->current_test - $first_test;
    };
};

until ( wait == -1 ) {
    my $num_tests_child_ran = $? >> 8;
    diag "child terminated after running $num_tests_child_ran tests";
    $Builder->current_test( $Builder->current_test + $num_tests_child_
+ran );
};
[download]

• log the traffic (at either a semantic level or a network level, depending on the particulars of the application), if possible, from a real scenario from your "control" code base (that is, either set up a monitor between the client and the server, or alter the client or server to embed a logging capability).
• make a mock client which can replay the same traffic to the server, and track the output from the server, also vice-versa with a mock server (or only use a mock client if you only want to test the server, or vice-versa).
• use the "control" logs obtained from the logger/monitor, and the mock client/server to play the same traffic back against the test codebase, and, likewise monitor it.
• diff the control logs versus the test logs.

Of course, the method is generally applicable to anything that allows you to spoof the client or the server (and I've used it for more than just web servers), but web servers make a nice example. A more general method would be simply to trap all the traffic on the socket and write it to a file (tracking what is server talking and what is client talking), and then play the one sides half of that conversation into the other side by, well, basically pasting it into a telnet window :-)

This model is very helpful for situations where you want to make sure that no unexpected changes occured between your control and your test version. Obviously, you'll want to identify differences and decide whether or not they are expected differences. It's often useful to munge the diff (systematically remove approved differences), and/or to munge the input's to the diff (likewise, as a way to systematically remove differences... but actually by making the inputs more similar, rather than by clipping the output of the diff, which can often be more difficult).

------------
:Wq
Not an editor command: Wq
[download]