httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Phillips <Nick.Phill...@stonebow.otago.ac.nz>
Subject Re: Perl test framework, TestConfig, and debugging A::T
Date Mon, 19 Jan 2004 19:37:13 GMT
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 / nick.phillips@stonebow.otago.ac.nz
# these statements are my own, not those of the University of Otago


Mime
View raw message