Doug MacEachern wrote:
On Thu, 8 Nov 2001, Stas Bekman wrote:
that won't work. The condition argument must return a single value, or it'll mess up the magic we have at the end of %args Test::plan expects.
right. there's got to be a better solution to this than have to check if the return value length == 1.
we could cook an errno like tied dual variable, which will test true/false on numerical test and give the string on "" op. Or would that be too much of an overkill?
Originally I've suggested to return a ref to a hash, since it wasn't used yet. {$meets_condition => "failure reason"}.
that would still break expr if have_module(...);
that's correct, I was thinking only about plan(). So it's not good.
can you please explain why do you want to mix the two? What similarity the two types have?
like in t/ssl/all.t: plan tests => 1, [$vars->{ssl_module_name}, qw(LWP::Protocol::https)];
and t/modules/dav.t: plan tests => 14, [qw(dav HTTP::DAV)];
don't want to have to write: plan tests => 1, [have_module_c($vars->{ssl_module_name}), have_module_perl('LWP::Protocol::https')];
plan tests => 14, [have_module_c('dav'), have_module_perl('HTTP::DAV')];
Now I understand, thanks.
So what do you suggest to write as a reason when mod_foo is not available? As you've mentioned before there could be many reasons (apxs undef'ed, v2 vs v1, etc) and they are definitely not the job of the test to know.
In any case as you say the Perl modules aren't expected to start from lowercase letter, therefore it should be at least
if (/^a... c case else perl case
what's the point of 'require mod_foo'?
I guess I don't understand you. What you have suggested earlier is to add a special variable, so tests can set it if they have a reason to fail.
First this requires changing tests to set the reason.
either way, as you've shown, requires a change to the test to set the reason. doesn't have to be a special variable, the point in the message was simply that tests will need to be able to describe reasons why tests are being skipped.
Oh, of course, I absolutely agree here.
2. have a special class variable:
$Test::FailureReason which can be set by any of have_foo functions on failure and allows the test writer to set it as well.
This will allow us to keep tests simple and let have_foo subs to report the reason, without taking away the flexibility of being able to set this variable from within the test.
since the majority of tests will only skip tests based on have_foo not being available, how about this. an @Apache::Test::SkipReasons array, where have_foo inside will push @SkipReasons, "..."; if foo is not available. then for the few special cases such as t/apache/getfile.t:
my $condition = sub { $perlpod };
Apache::Test::skip_reason("no .pod files in $vars->{perlpod}",
$condition);
plan tests => @pods + keys(%other_files), $condition;
that runs the $condition twice. How about:
my $condition = sub { $perlpod };
plan tests => @pods + keys(%other_files), skip_unless($condition, "reason");then skip_reason does this:
while (my($reason, $condition) = splice @_, 0, 2) { push @SkipReasons, $reason unless $condition->(); }
and skip_unless() will take care of pushing the reason into @SkipReasons if the condition has failed. This doesn't expose yet another sub into the tests.
plan() in this case will see that $condition->() fails and the reason(s) will already be present in @SkipReasons.
in my suggested case skip_unless() returns true/false, no need to rerun the condition.
i just don't want to loose the current functionality of:
plan tests => $n, [qw(foo Bar::Baz)];
and
if (have_module('Foo::Bar')) { ... }
sure, I understand now.
_____________________________________________________________________ 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/
