httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: Perl test framework, TestConfig, and debugging A::T
Date Mon, 19 Jan 2004 13:48:03 GMT

> 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?

you're thinking about it too much...

Apache-Test executes tests, such as foo.t, and the results of these tests
are fed to Test::Harness.  in this respect it is no different than any other
Perl test environment.  in fact, you can use Apache-Test to run basic Perl
tests that have nothing to do with a server and they work just fine.

but the reason you're using Apache-Test is to make requests against a
server.  if used in this way, foo.t is really the client (like your browser)
- it issues requests and can compare responses - status codes (like 200),
headers (like Content-Type), cookies, etc.  so, if you are testing an
authentication module, you can pass in usernames and passwords and use foo.t
to test whether your module is behaving properly.  and you _still_ don't
need to worry about the response handler.

however, remember that it's still Test::Harness that is doing the heavy
lifting - plan() feeds into Test::Harness, as does ok(), all printing to
STDOUT the things that Test::Harness needs.  see the Test::Harness manpage.

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.  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.

so, Apache-Test is _very_ flexible, and you can tune it to meet your many
differing needs.  try not to get bogged down too much with assigning roles
to each and every part - as you look at the examples out there use it
yourself it will start to make sense.  hopefully :)

--Geoff


Mime
View raw message