On Sat, Jan 17, 2004 at 09:59:03AM -0500, Geoffrey Young wrote:
> > There's one last piece that I'm still unclear on which your article did
> > not mention--reponse handlers. Is this where the two paths diverge? I'm
> > not sure that I see much difference between the way you do it and the
> > highly magical stuff.
>
> well, that's the next step. instead of calling plan() from within the test
> script, you can call
>
> plan $r, tests => 5;
>
> from within a handler() subroutine in a PerlHandler. but again, you don't
> need to use the magical parts of Apache-Test to autogenerated all the foo.
> that is, you can still write your own foo.t and extra.conf.in or whatever
> else you need.
I see why you call this code magical. It's definitely a step beyond my
understanding and probably beyond my needs for now.
> if you understand that no matter what wrapper you use - Apache-Test,
> Test::More, etc - in the end they are all just feeding "1..5" and "ok" to
> Test::Harness, then it all kinda makes sense - of course you can plan() and
> ok() from either a PerlHandler or *.t, so long as the proper sequence of
> data is printed to STDOUT.
OK, I'm beginning to see now. I was able to take my revised skeleton and
replace Apache::Test with Test::More. I had to modify the plan line to
remove the have_lwp() as that must be part of the Apache::Test module.
After that, everything worked!
Then I discovered that I can use both Apache::Test and Test::More
together with the following calls:
use Apache::Test qw('have_lwp');
use Test::More;
As you're no doubt aware, without the qw('have_lwp'), T::M overrides
subroutines like 'ok' in A::T. I was even able to add my usual test
module into the mix--HTTP::WebTest. Hey, I think things are gel'ing!
So each developer can run their own Apache process and test against it
as if it were the production server. You could even use the same binary
that is running the production server though you probably wouldn't want
to do intensive testing on a production platform. This test environment
rocks!
I still don't understand the driving need for writing tests that use
PerlHandlers but it seems best for me to leave that part of the test
framework alone until my knowledge matures.
One last question for now. Is there a way to pass additional arguments
into my scripts besides using environment variables? I use the
HTTP::WebTest module to do both local and remote testing. It'd be nice
to be able to pass an option to it to tell it to go into remote mode. I
guess doing something along the lines of the following is good:
TEST_REMOTE=1 t/TEST -run
I suppose the other option would be to write another test that would
only run if the above environment parameter is passed. Is there a better
way that folks here are using? I suspect this is rather non-standard
usage of test suites so it may be better to put my remote tests into
another location.
Many thanks!
William
--
Knowmad Services Inc.
http://www.knowmad.com
