Michael G Schwern wrote:
On Wed, Dec 01, 2004 at 12:44:50AM +0100, Paul Johnson wrote:
plan tests => 14, if => have( "Foo" ) && moon_phase eq "waning";
The downside here, as Geoff alluded to, is that we don't really want the short circuiting behaviour of &&, since evaluating the operands may give useful information as to why the tests are being skipped.
Actually we do. Consider the following.
plan tests => 14, if => os("Win32") && check_something_win32_specific;
Now there is something rather important missing from this discussion.
The skip reason. Everything proposed so far is only taking into account
the conditional.
well, not everything :)
But the real thing we want to condense is this.
if( some_condition ) { plan tests => 14; } else { plan skip_all => "the reason we're skipping this test"; }
The "need" functions must express two things.
1) Whether or not the test should be skipped. 2) Why the test is being skipped.
A simple solution is for need functions to return 0 if the need is met,
and the reason for skipping if the need is not met. Because this is
backwards logic we should rename the functionality to better match the logic.
For example.
sub need_module { my $module = shift; eval qq{use $module}; return $@ ? "Can't load $module" : 0; }
I'm not totally pleased with having "backwards" logic but it does seem the simplest way to do it.
which is fine, unless you want to layer conditions. I think we can accomplish both. in A-T we allow for two different flavors:
# if need_lwp() fails, perl will stop and only 'lwp not found' is printed plan tests => 3, need_lwp && need_module('LWP::Protocol::https');
and
# if both fail both skip messages are printed, else whichever failed plan tests => 3, need need_lwp, need_module('LWP::Protocol::https');
Maybe this is too little for too much. The only thing that's really being provided is a little "economy of expression". The same thing can be accomplished by encoding the prereqs in a sub:
sub provides_lwp_and_services {...}plan tests => 3, when => \&provides_lwp_and_services, because => '...';
I liked the initial idea, I'm just not sure the payoff is really there.
Randy.
