> I see why you call this code magical. It's definitely a step beyond my
> understanding and probably beyond my needs for now.
:)
> 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!
cool. actually, I've been meaning for a while to create a :testmore import
target that exports everything but ok() and plan() (the two that collide
with Test::More). but other than that, so long as you call Test::More::plan
you can use all the Test::More comparison functions, as well as things like
t_cmp() from Apache::TestUtil.
>
> 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!
that's what we've been saying all along.
;)
>
> 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.
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.
>
> 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.
I've always used environment variables. for instance, when I was testing a
SOAP client API, I defaulted my SOAP server to localhost, but used
%ENV{SOAP_SERVER} (or somesuch) if available. this let me run the same
tests against both my local extra.conf.in and the production box I was
setting up.
HTH
--Geoff
