Randy W. Sims wrote:
Adam Kennedy wrote:
Randy W. Sims wrote:
Adam Kennedy wrote:
This works:
---test.pl---
use Test::More tests => 1;
my $Test = Test::More->builder;
my $counter = $Test->current_test;
print qx!perl t/response.pl!;
$Test->current_test($counter + 1);
But why 1? Why not 5? or 10?
It has to be set to the number of tests run in the other process. I
don't know if there is a way to do something like no_plan for the sub
process... I don't think so... Every time pass(), ok(), etc is called
it updates the counter. In the sub process there is no way to pass
back the internal counter, so you have to update the counter manually.
Well, that would be why you allow the sub-process's plan code to run
as normal. When you get the fragment back, you can update it from the
header or the foot, but not print the actual header/footer.
You mean capture the output from the child process? Then allow the
parent to generate the test output from the captured & parsed output of
the child? That would mean for any lengthy child process there would be
a pause until the child completed; only then would the parent output the
results from the child. Otherwise, I guess you could Tee the output from
the child.
Is that what you mean by getting the fragment back?
Well, what I had actually intended originally for my implementation was
that you would split off the server process and have STDOUT/ERROR
writing to a known file.
Then either explicitly or at END time, the main script would collect up
the files for however many async things it had spawned off, and attach
them to the end.
So rather than having the tests intermingling down the test output,
they'd be in a seperate block at the end.
But then in doing that I was trying for the most simple approach I could
think of.
So by getting the fragment back I'd been thinking more in terms of
loading the fragments after the forked server was finished.
Adam K
