Re: Exiting a test script if a test fails

2004-02-27 Thread William McKee
On Fri, Feb 27, 2004 at 11:16:54AM -0800, Stas Bekman wrote: > What happens is that the client needs to read the output from the server > and then flush it out to Test::Harness. But if you server side dies it > won't send to the client the magic 'Bail out!' string. So what you could do > is inst

Re: Exiting a test script if a test fails

2004-02-27 Thread Stas Bekman
William McKee wrote: On Thu, Feb 26, 2004 at 04:05:02PM -0800, Stas Bekman wrote: it works perfectly fine for me. You need to do that call in the *client*. Doh! My poor brain is still having trouble with this distinction . The trouble is that the script I need to bail out of is a response test (se

Re: [PATCH] fix @INC when running all.t

2004-02-27 Thread Stas Bekman
Rodent of Unusual Size wrote: Joe Orton wrote: my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test lib); my $cmd = "$^X -Mlib=$lib $file"; i don't think catfile does things like space-escaping, so wouldn't my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test lib); my $cmd =

Re: running singleton tests, and individual descriptions

2004-02-27 Thread Rodent of Unusual Size
Joe Orton wrote: > > This is possible if the test script is written to use sok: > > http://perl.apache.org/docs/general/testing/testing.html#Running_only_Selected_Sub_tests um, unless i'm reading the source wrong, ok invocations can NOT be simply changed to sok. sok requires something executabl

Re: running singleton tests, and individual descriptions

2004-02-27 Thread Rodent of Unusual Size
Joe Orton wrote: >> >> 1. the inability to run a *single* test within a script. > > This is possible if the test script is written to use sok: > > http://perl.apache.org/docs/general/testing/testing.html#Running_only_Selected_Sub_tests aha. thanks. what odds of this ever getting back into the

Re: Exiting a test script if a test fails

2004-02-27 Thread William McKee
On Thu, Feb 26, 2004 at 04:05:02PM -0800, Stas Bekman wrote: > it works perfectly fine for me. You need to do that call in the *client*. Doh! My poor brain is still having trouble with this distinction . The trouble is that the script I need to bail out of is a response test (server side). I guess

Re: skipping and installing

2004-02-27 Thread Geoffrey Young
>>so, it looks like an issue with your wrapper and not A-T >>core, yes? > > > no. if i run only a test script that passes completely, i get > > t/modules/accessok > All tests successful. > Files=1, Tests=408, 4 wallclock secs ( 3.13 cusr + 0.43 csys = 3.56 CPU) > > if i run only a script

Re: running singleton tests, and individual descriptions

2004-02-27 Thread Joe Orton
On Fri, Feb 27, 2004 at 07:54:07AM -0500, Ken Coar wrote: > two aspects of the framework that i consider deficiencies are: > > 1. the inability to run a *single* test within a script. This is possible if the test script is written to use sok: http://perl.apache.org/docs/general/testing/testing.h

Re: [PATCH] fix @INC when running all.t

2004-02-27 Thread Rodent of Unusual Size
Joe Orton wrote: >> >> my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test lib); >> my $cmd = "$^X -Mlib=$lib $file"; i don't think catfile does things like space-escaping, so wouldn't my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test lib); my $cmd = "$^X -Mlib=\"$lib\"

Re: running singleton tests, and individual descriptions

2004-02-27 Thread Rodent of Unusual Size
Rodent of Unusual Size wrote: > > one solution to this one would be to a) have guidelines about the > test descriptions, such as > > ok($result eq $expected, "f(x): expected '$expected', got '$result'"); > > so that what was being attempted is clear better still, if there was something like %

running singleton tests, and individual descriptions

2004-02-27 Thread Rodent of Unusual Size
two aspects of the framework that i consider deficiencies are: 1. the inability to run a *single* test within a script. 2. the lack of per-test descriptive text. i realise the first is essentially insurmountable, given the structure, design, and implementation of the perl testing mechanism. (why

Re: skipping and installing

2004-02-27 Thread Rodent of Unusual Size
Geoffrey Young wrote: >> >> bugger. if the bloody package continues running through the rest of >> the tests even after encountering a failure -- which is right, and what >> it does -- it should use a uniform report syntax and most certainly *not* >> conceal details about the totals.. :-( > > I

Re: [PATCH] fix @INC when running all.t

2004-02-27 Thread Joe Orton
On Fri, Feb 27, 2004 at 03:04:20AM -0800, Stas Bekman wrote: > Joe Orton wrote: > >It works if you also have Apache-Test installed in the system site_perl > >directory of course, which I have on most boxes so only just noticed > >this. This fixes it for me, OK to checkin? > > Yup. That's one of t

Re: [PATCH] fix @INC when running all.t

2004-02-27 Thread Stas Bekman
Joe Orton wrote: The all.t tests are all failing for me on HEAD with errors like: Can't locate Apache/Test.pm in @INC (@INC contains: ../Apache-Test/lib /usr/lib/perl5/5.8.1/i386-linux-thread-multi /usr/lib/perl5/5.8.1 etc etc .) at t/ssl/all.t line 4. from an strace, the cwd of the process is

[PATCH] fix @INC when running all.t

2004-02-27 Thread Joe Orton
The all.t tests are all failing for me on HEAD with errors like: Can't locate Apache/Test.pm in @INC (@INC contains: ../Apache-Test/lib /usr/lib/perl5/5.8.1/i386-linux-thread-multi /usr/lib/perl5/5.8.1 etc etc .) at t/ssl/all.t line 4. from an strace, the cwd of the process is the top-level pe

Re: Exiting a test script if a test fails

2004-02-27 Thread Stas Bekman
William McKee wrote: On Thu, Feb 26, 2004 at 01:17:08PM -0800, Stas Bekman wrote: I tried to use it when I was messing with the pre- and post-test foo a while back, but couldn't get it to work. it might have had something to do with the massive other changes I was trying to implement at the time,