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