httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Perl test framework, TestConfig, and debugging A::T
Date Mon, 19 Jan 2004 20:23:02 GMT
Geoffrey Young wrote:
>>>now, Apache-Test gets tricky.  it _also_ makes sure that the server
>>>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     mod_perl Guide --->

View raw message