On 20/01/2004, at 2:48 AM, Geoffrey Young wrote:
So let me see if I follow you. The request script is the client and should output the test results. The response handler is handling the server-side requests. It can send information back to the client to output. It looked, though, like Geoff was using examples such as plan $r, tests=>9 in the response handler examples he was writing to me about. Was this incorrect usage or can you do testing in the response handler which you pass back to the request handler to output?
If you don't write a client script yourself, A-T automatically generates one which simply passes the output of the response module through to Test::Harness, so you're fine either way.
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
from within a response handler. in this case, you use foo.t solely to issue
a single request to the server, and let the server decide what is ok() and
what is not.
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, it's simply that once the (possibly
autogenerated) client script gets hold of the response, it doesn't bother
with any interpretation, rather it just passes it straight on to
Test::Harness.
It's just a question of which side of the HTTP bit you decide to stick the
test logic. You can even mix it up (probably a bad idea, though ;-)).
If I get time I'll try to draw it; I think that would probably help a lot.
where this is useful is when you need to test parts of the
module itself, not the end results as far as the client is concerned. for
instance, if your authentication module provides an API that is supposed to
return the name of the DB server that is doing the authentication, you could
test that here.
Alternatively, you could decide that you want to keep the test logic in the
client script (the .t bit), and just output a page containing
"DB Server: foo" in the response handler. The client script could then parse
this. It's just that it's simpler in this case to stick the actual test logic
in the handler as well, as Geoff suggested.
so, Apache-Test is _very_ flexible,
Amen to that!
Cheers,
Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago
