On 17/01/2004, at 4:12 PM, Stas Bekman wrote:
Geoffrey Young wrote:
[...]
I'd like to second Geoff comments on the fact that it's a complex
stuff. And we are here to help. And you are here to remember/write
down all the unclear things and help improve the docs so the next time
you need to do it
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 sectio
On Sun, Jan 18, 2004 at 10:57:25AM -0500, Geoffrey Young wrote:
> 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.
Now that you mention i
>>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
On Sun, Jan 18, 2004 at 12:38:15AM -0800, Stas Bekman wrote:
> >William, the cvs version of Apache-Test now has this bug solved. So if
> >you want to use that APACHE solution try it. Though the suggested above
> >solution is more efficient, as it won't reconfigure the test suite on
> >every t/TE
On Sat, Jan 17, 2004 at 02:35:17PM -0500, Geoffrey Young wrote:
> 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).
That'd be very useful!
> well, it's important if you're wr
Stas Bekman wrote:
William, the cvs version of Apache-Test now has this bug solved. So if
you want to use that APACHE solution try it. Though the suggested above
solution is more efficient, as it won't reconfigure the test suite on
every t/TEST run.
Though I've also changed the env variables in
Stas Bekman wrote:
Geoffrey Young wrote:
Stas Bekman wrote:
Moreover the prefix
ideally should be: APACHE_TEST_ and not APACHE_, since we already have a
bunch of env vars which start with APACHE_TEST_
Though I'm in favor to just drop them, making
everybody move to the better API.
+1
Thanks Geof
Stas Bekman wrote:
Stas Bekman wrote:
I've reproduced the problem:
setenv APACHE /home/stas/httpd/1.3-dynamic/bin/httpd
t/TEST -v -trace=debug -port select
t/TEST -v -trace=debug
one the first run, extra.conf.in is parsed:
Including /tmp/bug-reporting-skeleton-mp1/t/conf/extra.conf config file
gene
[EMAIL PROTECTED] wrote:
stas2004/01/18 00:08:39
+if $self->{reconfigure} is true, make sure to perform a complete
+reconfiguration, to solve the bug where conf.in files weren't reparsed
+and vhost hostport info was getting lost on subsequent runs when
+APACHE env var was set (one
Stas Bekman wrote:
OK, I've written the missing spec for the A-T custom config (it's in the
at the end of Apache::TestRun pod), please check that it's sane and that
I haven't missed some possible cases. This is a top level spec with many
details explained in the code.
Next I did another iterati
Geoffrey Young wrote:
In any case, adding a check for a file is fine with me as long as you
s/warning/debug/, so it won't appear in the normal output and users
don't send false complaints. How about adding it as an extra check on
top of this patch?
that all sounds fine.
Thanks Geoff. I've added t
Randy Kobes wrote:
On Sat, 17 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
I don't have an ~/.apache-test/, and yes, using the perl
with the CPAN A-T installed to build the cvs A-T is fine.
Where I run into problems in not seeing the configuration
dialogue is using the perl with the cvs
On Sat, 17 Jan 2004, Stas Bekman wrote:
> Randy Kobes wrote:
[ ... ]
> > I don't have an ~/.apache-test/, and yes, using the perl
> > with the CPAN A-T installed to build the cvs A-T is fine.
> > Where I run into problems in not seeing the configuration
> > dialogue is using the perl with the cvs
Geoffrey Young wrote:
ok, here's my latest problem...
given a 3rd party module installation
$ perl Makefile.PL -apxs /foo/bin/apxs
two issues arrive
1) $HOME/.apache-test is created when the tests are run, not when the module
is installed. which means that even without any actual installs
This is
OK, I've written the missing spec for the A-T custom config (it's in the at
the end of Apache::TestRun pod), please check that it's sane and that I
haven't missed some possible cases. This is a top level spec with many details
explained in the code.
Next I did another iteration on the code, cha
Randy Kobes wrote:
On Tue, 13 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
I haven't worked through this yet, but I find a similar
problem ... I have two Perls, both of which have mp2
installed, but one has the CPAN Apache-Test and the other
has the cvs Apache-Test installed. In building the
cv
17 matches
Mail list logo
