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 Sat, 17 Jan 2004 19:35:17 GMT

> 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


Mime
View raw message