Re: perl-framework: mod_dav but not mod_dav?
On Tue, 4 Dec 2001, Stas Bekman wrote: Actually, we don't have to run -t to test for failure, since the normal execution fails as well and for all cases (not only syntax errors). The problem is that we run: system command ; we can run $cmd -t| before that and check if the output contains Syntax OK or not.
Re: cvs commit: httpd-test/perl-framework/t/apache getfile.t
Doug MacEachern wrote:
On Thu, 22 Nov 2001, Stas Bekman wrote:
I can extend it to engulf the plan() extension that we have added and then
the only function you will ever call with plan() is skip_unless. I
think this:
plan ..., skip_unless('cgi', 'lwp');
there's no point in overloading plan anymore then. we should just change
it to:
skip_unless(...);
plan tests = $tests;
and have skip_unless() print 1..0\n...; exit; if conditions are not met.
sounds good.
personally, i would rather keep the the current plan shorthand and change
skip_unless to be called as it is above.
I didn't get you? do you prefer to make this change and disengage skip
stuff from plan:
skip_unless(...);
plan tests = $tests;
or do you prefer:
plan ..., skip_unless('cgi', 'lwp');
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [patch] more robust startup + counting
On Wed, 5 Dec 2001, Stas Bekman wrote: I suggest having an APACHE_TEST_CRON_MODE env var which will also replace APACHE_TEST_NO_COLOR. Sounds OK? i'd just rather have a different name. this'll be useful for more than cron. in fact i'd be happy to stick with APACHE_TEST_NO_COLOR.
Re: cvs commit: httpd-test/perl-framework/t/apache getfile.t
On Wed, 5 Dec 2001, Stas Bekman wrote: I didn't get you? do you prefer to make this change and disengage skip stuff from plan: skip_unless(...); plan tests = $tests; i'd like it if the current shorthand continues to work: plan tests = $tests, ['lwp', 'cgi']; i would not like it if the only option to plan was the return value of skip_unless. so if the skip_unless extensions do not fit into the overloaded plan, then just detach it like you have above. we only call it in one .t at the moment (byterange), and i guess one more would call it if the extension is made (getfile).
Re: [patch] more robust startup + counting
Doug MacEachern wrote: On Wed, 5 Dec 2001, Stas Bekman wrote: I suggest having an APACHE_TEST_CRON_MODE env var which will also replace APACHE_TEST_NO_COLOR. Sounds OK? i'd just rather have a different name. this'll be useful for more than cron. in fact i'd be happy to stick with APACHE_TEST_NO_COLOR. so be it. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: perl-framework: mod_dav but not mod_dav?
On Wed, 5 Dec 2001, Stas Bekman wrote: ok, but that catches only syntax errors. if we can catch the return status from system() we can catch all errors, causing the failure. that would be great.
Re: cvs commit: httpd-test/perl-framework/t/apache getfile.t
Doug MacEachern wrote:
On Wed, 5 Dec 2001, Stas Bekman wrote:
I didn't get you? do you prefer to make this change and disengage skip
stuff from plan:
skip_unless(...);
plan tests = $tests;
i'd like it if the current shorthand continues to work:
plan tests = $tests, ['lwp', 'cgi'];
i would not like it if the only option to plan was the return value of
skip_unless. so if the skip_unless extensions do not fit into the
overloaded plan, then just detach it like you have above. we only call it
in one .t at the moment (byterange), and i guess one more would call it if
the extension is made (getfile).
having two places where the test can be told to skip is confusing. So
you only want to preserve:
plan tests = $tests, ['lwp', 'cgi'];
i.e. the ref eq ARRAY part in the original implementation of overloaded
plan().
Otherwise I think I can fit skip_unless as a function that can handle
*any* requirement. e.g.:
+ skip_unless({sub {$a==$b} = $a != $b!
+ sub {$a==1} = $a != 1!},
+ 'LWP',
+ 'cgi_d',
+ {sub {0} = forced to be skipped},
+ );
is that ok?
If so we advise users to use skip_unless() everywhere and [qw(foo bar)]
as a shortcut.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [patch] adding the startup polling functionality
Doug MacEachern wrote: On Wed, 5 Dec 2001, Stas Bekman wrote: I didn't suggest to change how the default -run works (see the patch). but you did ask: - any reason for not making -poll turned on by default for -run? sorry, I've missed this one. I've suggested a new option -poll, which when used will poll the server till it starts. since it's the same as -ping=block for ping, I've removed the =block part. right. i suggested making '-ping=block -run' work as expected rather than adding a new -poll option. with mnemonic: block until ping and then run? the problem is that ping is an exit option, will have to change things a bit. I still like the new -poll option, since in the future we may extend other options functionalities to poll too. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [patch] more robust startup + counting
Doug MacEachern wrote:
one thing we need to fix with this new feature is the ability to turn
off this output. for the same reason we have $ENV{APACHE_TEST_NO_COLOR}
to turn off the colors. for when t/TEST output is redirected to a file,
like from a cron job. at the moment t/TEST test.log outputs a bunch of
waiting for server to start: 00:nn. maybe have one ENV var to turn off
all things like this, APACHE_TEST_SIMPLE_OUTPUT or something.
How about APACHE_TEST_BATCH_OUTPUT?
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
All right everyone! Step away from the glowing hamburger!
Re: Testing remote server
Doug MacEachern wrote: Not without some trickery: loads of the scripts rely on being able to write directly to the server root. we should fix that. the original plan was for this to work: % t/TEST -run -port 8080 -servername foo and have the .t's hit http://foo:8080 Was 'foo' supposed to be a vhost on the current system, or was it supposed to be able to be a remote system? The latter is my goal (testing things like DAV on Win32 bites the Harry Houdini..). -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: Testing remote server
as was mentioned earlier, some test write to the server root, perhaps we could add a special directive so you could do something like this in your plan line: plan tests = 5, have_module 'foo' have_local_server_root where 'have_local_server_root' could be named whatever we think appropriate and is set to 1 unless -servername is specified on the command line. then tests that require access to server root could be skipped when you are testing on a remote host. whatchooguysthink? -j On Tue, Dec 04, 2001 at 02:50:07PM -0500, Rodent of Unusual Size wrote: + Doug MacEachern wrote: + + Not without some trickery: loads of the scripts rely on being able to + write directly to the server root. + + we should fix that. the original plan was for this to work: + % t/TEST -run -port 8080 -servername foo + + and have the .t's hit http://foo:8080 + + Was 'foo' supposed to be a vhost on the current system, or + was it supposed to be able to be a remote system? The + latter is my goal (testing things like DAV on Win32 bites + the Harry Houdini..). + -- + #ken P-)} + + Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ + Author, developer, opinionist http://Apache-Server.Com/ + + All right everyone! Step away from the glowing hamburger!
Re: Testing remote server
On Tue, 4 Dec 2001, Rodent of Unusual Size wrote: Was 'foo' supposed to be a vhost on the current system, or was it supposed to be able to be a remote system? The latter is my goal (testing things like DAV on Win32 bites the Harry Houdini..). the latter.
