now, Apache-Test gets tricky. it _also_ makes sure that the server response gets funneled to Test::Harness if you use the plan $r, tests => 9 syntax
I think this makes it sound trickier than it needs to; AIUI the feeding the results back to Test::Harness is nothing to do with what syntax you use in the response handler module
but it does - if plan recieves $r as a first argument, the response is tied to STDOUT so that Test::Harness can read it. if you didn't do that, prints to STDOUT would end up being content sent to the client.
But that's exactly what is happening. Test::Harness runs only only the client side, it actually runs the clients. Test::Harness in the A-T setup has no idea the server side exists at all. The server side can run ok/skip/etc via Test, Test::More, Apache::Test, etc. it then sends the output of these ok/skip/etc to the client as a normal response, which feeds it to Test::Harness.
You don't have to pass $r to plan() to get the server side tests working. It's just done for your convenience in the 'SetHandler modperl' mode, which wants you to do $r->print() and not print(). Since ok() will just print() the output won't go anywhere, since STDOUT is not tied/perlio'ed. So once you pass $r to plan() it just performs that trickery for you.
So yes, 'plan $r' has to do with STDOUT, but no, it has not much to do with Test::Harness besides helping the server to send the response to the client.
I suppose that this is your understanding as well, it just wasn't clear from the above para, as it lost the server->client link.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
