On Jan 23, 2009, at 1:11 AM, Eric Wilhelm wrote:
If so, you're using the plan as something like a stand-in for the
assertion:
my @resources = $manager->resources;
is(scalar(@resources), 12, "have 12 resources");
And actually, you probably want to assert something like:
my @resources = $manager->resources;
is_deeply([sort(@resources)], \...@expect_resources);
Which fails more descriptively than a plan failure.
Well there you've just solved your loop problem, haven't you? I think
you've proven that removing the plan is not the right solution to the
problem.
But all this test() function does -- accounting for perl 5
limitations -- is to run a block of who-cares-how-many assertions and
guarantee that the block returns. It only emulates is_deeply() in
that
regard (and without messing with tap it would simply emit a single
ok.)
But you've just shown how you don't even need it. Problem solved. ;-)
And yes, iterators reintroduce the halting problem because everything
has trade-offs. Nonetheless, you can still magically deduce that
we're
done_testing() because if any test{} didn't return we hit exit() or
whatever in the middle. You can also potentially produce some
semblance of a progress report.
I fail to see how this is simpler than typing a plan.
Certainly, I find that the numeric plan is clunky and no_plan is too
unguarded. The done() is a step. The numeric plan is not strictly
necessary and I think any assertion it performs can be achieved (with
better diagnostics) by actually asserting that what you intend to do
is
done as intended. Maybe that logical transformation from one number
to
@things and @stuff is not for everyone or is considered overly
prescriptive, but there's more than one way to do it and perhaps even
three.
I don't trust the computer to properly calculate the plan. I therefore
like being able to put it in myself. It's a test! And if the computer
calculates it, it's not a test anymore.
To me, it's not clunky. It does exactly what I expect it to do.
Best,
David
