# from David E. Wheeler
# on Friday 23 January 2009 09:04:

>>  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.

I thought I was proving that the plan bundles a bunch of unrelated 
assertions into a single number.

>> But all this test() function does...
>
>But you've just shown how you don't even need it. Problem solved. ;-)

I don't think so.  If we are going to be able to defer running the test 
blocks, we still need test functions which take blocks.  But given that 
perl 6 has multi subs, we could:

  ok {... ; $ok} "what";
  is_deeply {...; @data} @want, "deep thing";

Though that does break the expectation that assertions are run in-flow 
with the rest of the code.

>> 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.

I don't recall claiming that it was *simpler*.  The single static 
numeric plan is simplistic.  Given any cross-platform skip issue or 
optional-dependency condition, you have a situation where the plan 
becomes harder for a human to get right.  In that case, I want to 
program the test to react to the environment rather than shipping the 
wrong plan.

>>  Maybe that logical transformation from one number to
>> @things and @stuff is not for everyone 
>
>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.

The @things and @stuff could be hard-coded.  Do you trust the computer 
to calculate the length of a list?

--Eric
-- 
"I've often gotten the feeling that the only people who have learned
from computer assisted instruction are the authors."
--Ben Schneiderman
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Reply via email to