> 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
