2009/1/23 Eric Wilhelm <scratchcomput...@gmail.com>:
> # from Fergal Daly
> # on Friday 23 January 2009 10:18:
>
>>sub test_foo {
>> increment_plan_by(3);
>> ok(foo(1), "foo1 test");
>> ok(foo(2), "foo2 test");
>> ok(foo(3), "foo3 test");
>>}
>>
>>but you forget add an actual test_foo() call or due to some bug, the
>>call is skipped. Your tests will happily complete and your plan will
>>declare itself to be correct because it is too close to the tests.
>
> This is true, but I'm equally likely to not adjust the static numeric
> plan anyway.
Maybe you are but I'm not.
> It seems like this case suffers from its own definition. If we adjust
> the construct such that the planning is implicit and calling is
> guaranteed:
>
> test_list [1,2,3] { ok(foo($_), "foo$_ test"; };
>
> If you somehow didn't run that code, this is a different problem
> entirely. If I'm having such a bad day that I failed to write the code
> such that it actually executes, what says that I've managed to update
> the plan correctly or at all?
Because updating the plan is very simple and difficult to get wrong.
Updating code may be tricky and difficult to get right.
I don't really follow your example but I think you're trying to make
the plan part of the tests in which case of course the plan will
always be correct but serves no purpose any more.
Like I said before, the plan is a checksum that is easy for a human to
update. The declared plan is the checksum as calculated by hand by a
human based on what they hope their code will do. The other half of
the checking is when the test runs and the Test::Harness calculates
the checksum based on the test results that appear in the TAP.
You seem to be saying "calculating the checksum is tedious work for a
human and should be done by a computer" but in that case all you are
checking is that Test::Builder and Test::Harness agree on the tests
they saw running. Both of these values comes from the run time
behaviour of the code and will always be the same. Comparing them
captures nothing of the author's intention vs the run time and thus
will never catch any bugs.
Maybe I'm missing something but I can't tell the difference between
what you want and no_plan. If no_pan is what you want then that's fine
but other people want to plan,
F
> --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
> ---------------------------------------------------
>
