Hi...
It seems you are going through pretty much what I did a month or two ago.
http://perl.apache.org/docs/general/testing/ testing.html#Developing_Response_and_Request_Parts_of_a_Test
Thanks. I overlooked that the first time and am now getting documentation blindness. It seems that the section may be missing a configuration for the extra.conf.in. How is the /TestApache__cool uri getting defined?
Been there done that. That document, whilst it does actually contain a lot
of what you need, is hopelessly structured from the point of view of someone
who wants to learn how to make their tests work. By the time you get off the
stuff you already knew, you're half-asleep and unable to notice the bits that
are actually useful. It's a miracle that it manages to be seemingly
well-structured document containing so much useful information so damn hard
to use. I guess it's partly a result of it being written by someone who knows
it inside-out.
I've only been following this thread half-heartedly, but a number of the
questions you raise make me wonder if you've really read the available
documentation for Apache-Test.
Honestly, I am trying my best.
Had that feeling too -- again, people kept asking whether I'd read the same
bits of documentation. I had, or at least I thought I had, but the relevant
parts certainly weren't jumping out at me at the time.
The documentation that you pointed me to is starting to make sense.
And eventually Stas said something that triggered that in me, too. But I do
think that a better tutorial document is needed; I just don't have the time
to write one right now.
That would be helpful as it seems my test package is in dire straits.
I think the "eureka moment" for me was when Stas pointed out that you manage
the server side of the testing from handlers. The TEST program takes your
response module and uses it as a handler for the request in question. A whole
series of URLs are set up, one for each response part, with names generated
from the filenames of the response modules you've written. The request
parts of the tests can then test any of the response modules by requesting
the appropriate URL.
The other confusing bit was trying to get a handle on which bit is actually
controlling the test; which bit should actually output the test plan and the
"ok" and "not ok" stuff. It's the request script, but in many cases it is
convenient for the response module to output it into the response page, and
for the request script to just output that verbatim (particularly when you
are unit testing, as you said, subroutines used on the server side).
Hope that helps.
Cheers,
Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago
