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: Response Handlers (was Re: Perl test framework, TestConfig, and debugging A::T)
Date Sun, 18 Jan 2004 15:57:25 GMT

>>well, it's important if you're writing an API, not merely testing CGI
>>scripts or the like.  for instance, suppose you have a class that subclasses
>>mod_perl.  if you plan'd and ok'd things from a PerlHandler then you could
>>do things like
>>
>>  isa_ok($r, 'My::Class');
>>
>>which you can't really do otherwise.
> 
> 
> OK, let me see if I'm understanding. The response handler acts as a kind
> of subclass that sits between modules in the project's lib/ directory
> and requests. It's like a back-door into the code that is running on the
> server which allows you to make your tests even more complete.

pretty much, but I wouldn't call it a back door - it's web application
programming through the Apache/mod_perl API.

> 
> If this is correct, it's a very subtle distinction. The request test is
> essentially testing the response. However, it doesn't have direct access
> to the $r object that got created in response to the request--it just
> gets the final data being sent back. 

exactly.  you could, say, die() after every API call and test for 500 in
your foo.t, in which case you really don't know where the issue is.  or you
can just have foo.t call a PerlResponseHandler that does all the work for you.

it really depends on what you're trying to accomplish.  Apache-Test is for
what is generally called 'unit tests' or 'functional tests' - given known
input, make sure your code gives you the correct output.

so, you can use Apache-Test merely to control Apache activity - configure,
start, and stop the server - which gives you a pristine environment to test
against.  then you can unit test whatever you want, say CGI scripts (given a
certain query string produce a proper login screen).

in this case, mod_cgi is the response handler.

if you use mod_perl as the response handler for your application, then you
have more available in terms of the Apache API.  and you can use Apache-Test
to write unit tests against an API that you write to abstract out components.

> In this sense, it seems like the
> response test is like an Apache filter. If I'm grokking this correctly,
> this seems like an amazingly powerful tool which would be useful to
> testing an API but not as necessary for testing a web application unless
> you're getting some hard-to-track bugs happening.

it is incredibly powerful, yes :)

> 
> In Stas' example at perl.apache.org, he uses the url
> '/TestApache__cool' in the request test, cool.t. I saw the paragraph at
> the end of the section about developing response and request parts of a
> test which described the directory layout. However, I didn't see a
> discussion of how the url is created. I'm guessing that A::T takes all
> the directories and files in t/response and creates Locations which
> the test apache server can handle. Would the file
> t/response/Mod/hot.pm create a url of '/Mod__hot'?

this is the magic part.  but you don't need to worry about the magic to make
it all happen.  just configure extra.conf.in as you ordinarly would.  then
define your PerlResponseHandlers outside of lib/ - like in t/My/ :)  the
packages in t/My can call the API living in lib/ so you can test them.

using the magic is the next step, and is particularly helpful in largish
applications.  for me, I tend to use the simple approach most of the time.

--Geoff


Mime
View raw message