in reply to Test::More and fork

If it isn't the problem, what am I doing wrong?

The test output isn't the problem :-)

Test::Builder does some automatic checks when a process exits that, amongst other things, check that the number of tests run matches the number of tests in the plan.

After you fork the parent process doesn't know that the child process ran another test. This means when the parent process exits, it comes up one test short and outputs the error you see.

To get over this you can disable the exit checking by doing:

Test::More->builder->no_ending(1);

in the parent process - see the Test::Builder docs for details.

Replies are listed 'Best First'.
Re^2: Test::More and fork
by cees (Curate) on Jun 23, 2005 at 19:05 UTC

    Brilliant! adrianh++

    I missed that bit in the docs, but it works like a charm. I guess I was confused that Test::Harness couldn't see the correct number of valid tests either, but it must parse some of the end report that Test::More generates, instead of counting the tests itself.

    There is just one limitation (that doesn't affect me), but after the fork, you can't perform any more tests in the parent, because it will mess up the test numbering (since it doesn't see the tests the child has performed). However, you could disable automatic numbering and manage that yourself to get around it. For me it is not a big deal, since I don't need to perform any more tests in the parent after the fork.

    In case anyone is intereset why I needed this, I needed to test a CGI file upload, and the following allows me to simulate that perfectly (basic idea stolen from CGI.pm test suite):

    my $req = &HTTP::Request::Common::POST(
    '/dummy_location',
    Content_Type => 'form-data',
    Content      => [
        test   => 'name2',
        image1 => ["t/image.jpg"],
    ]
);
$ENV{REQUEST_METHOD} = 'POST';
$ENV{CONTENT_TYPE}   = 'multipart/form-data';
$ENV{CONTENT_LENGTH} = $req->content_length;
if ( open( CHILD, "|-" ) ) {
    print CHILD $req->content;
    close CHILD;
    exit 0;
}

# at this point, we're in a new (child) process
# and CGI.pm can read the POST params from STDIN
# as in a real request
my $q = CGI->new;

    [download]
[reply]
[d/l]
      I guess I was confused that Test::Harness couldn't see the correct number of valid tests either, but it must parse some of the end report that Test::More generates, instead of counting the tests itself.

      The reason T::H gives an error is that the when T::B figures out it has a bad test count it exits with a non-zero value, which then gets picked up as suspicious by T::H (which is why you got the "Test returned status 1" error from T::H).

      This makes it easier for other things like Aegis to figure out which test script borked automatically.

[reply]

In Section Seekers of Perl Wisdom