Eric Wilhelm wrote:
>> A. Pagaltzis wrote:
>>> ...
>>> which would still be an error. That way a mistake in a test
>>> script won’t lead to Test::More silently converting an up-front
>>> plan declarations into trailing ones.
>> Which brings us back to the original question: why should that be an
>> error?
>
> It's a matter of stricture? If the developer intended the plan to be
> before-hand, they'll be expecting an error to enforce that practice.
Why do they care if the plan is output at the beginning or end? How does this
stricture improve the quality of the test? What mistake does it prevent? If
we were to propose the "no test without a plan" stricture today, what would
the arguments in favor be?
I'm not worried about the shock of violating existing programmer's calcified
minor expectations. They'll live.
About the only thing I can think of is consistency. skip_all must still come
first, so that this sort of thing will sometimes work, sometimes not,
depending on $^O.
use Test::More;
if( $^O eq 'BrokenOS' ) {
plan skip_all => 'Your shit is broke';
}
else {
plan tests => 42;
}
BEGIN { use_ok 'Some::Module' }
This might be solved by the oft-requested "skip_rest".
use Test::More tests => 42;
skip_rest("Your shit is broke") if $^O eq 'BrokenOS';
BEGIN { use_ok 'Some::Module' }
Hmm, it's also shorter. This even allows something like this:
use Test::More tests => 42;
BEGIN {
use_ok 'Optional::Module' ||
skip_rest('Optional::Module not available');
}
> The current planning functions impose strictures. (Yes, it happens to
> be due to an old implementation detail which no longer governs -- but
> that doesn't change the fact that behavior expectations have already
> been set.) Taking away the error essentially means that you've changed
> the API. Imagine if strict.pm suddenly stopped being strict about
> symbolic refs.
>
> That is, users should somehow be able to rely on the same strictures
> that they've had in the past (hopefully by-default.) So, either this
> new non-strict plan scheme should be declared in the import() params or
> be not named plan().
I see where you're going, but I think this is going too far wrt backwards
compatibility.
The strict analogy is spurious because that would be changing a fundamental
part of strict. Whereas this is an incidental part of Test::More. Scale does
matter.
Furthermore, it's not going to cause any passing tests to fail, or any
legitimately failing tests (ie. due to a real bug, not Test::More stricture)
to pass.
The only breakage I can think of are all highly convoluted and improbable,
where you've somehow written a test that checks that this specific feature
works. But the only one who should be doing that is Test::More's own tests.
Or some highly paranoid dependent on that specific feature, in which case
congratulations! Your test did its job!
I'm not worried.
> I'm still wishing for the "plan to make it to a given statement" model
> (e.g. done().)
Honestly all that's really holding that up is a good name for the plan style
and "I'm done testing" terminator. Nothing has really lept out at me yet.
Maybe something as straight forward as...
plan 'until_done';
....
done_testing;
--
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
