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
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
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
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 those
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 can't say
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.
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
% t/TEST
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:
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 that fails,
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 g.
The trouble is that the script I need to bail out of is a response test
(server side). I
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 cpan
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 executable
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 =
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 g.
The trouble is that the script I need to bail out of is a response test
14 matches
Mail list logo
