2009/1/23 Eric Wilhelm <scratchcomput...@gmail.com>:
> # from Fergal Daly
> # on Friday 23 January 2009 02:07:
>
>>The point is that you want to declare your intention independently
>>from taking the action. If you declare the plan alongside performing
>>it, then your planning becomes subject to bugs.
>
> I'm sure that for every reason someone can cite about needing a
> statically coded numeric plan, I can point out in detail a method of
> refactoring such that the plan becomes a number which is at least
> closer to the data involved. If you generate the list of things to
> check, code in a test that this list is 7.
I'm not sure I understand the final sentence. It seems to me that
setting the plan to 7 is essentially such a test however it has the
advantage that it is declared early enough that it can't be
accidentally skipped.
> You simply need to assert what you mean to assert *where* you mean to
> assert it. That might be a static number in one place while in another
> place you might simply check for matched sets and so on.
Lets say you add this piece of code to your test
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 why the plan must be sufficiently far away from the tests so
that it is guaranteed to be declared even if the tests themselves
don't run.
I agree that having it all in one big integer at the top of the file
is not ideal.
With nesting, you can move some aspects of the plan closer to the code
(which is good) but you must always have some part of the plan far
enough away from the code so that it is not subject to the same bugs.
Ideally something like this would work
plan(3);
test1();
test2();
ok(1)
sub test1 {
plan(2);
ok(1)
ok(2);
}
sub test1 {
plan(5);
for $i (1..5) {
ok($i)
}
}
But that requires some magic to detect the end of the block so it
would have to look a little different. It also requires nested TAP. In
this example plan(x) means that the total number of tests and blocks
of tests should sum to x.
With a system like this, you only have to update the plan nearest to
the code but the plans are all far enough away from the code that none
of the blocks can be accidentally skipped over without missing them,
F
> --Eric
> --
> "Matter will be damaged in direct proportion to its value."
> --Murphy's Constant
> ---------------------------------------------------
> http://scratchcomputing.com
> ---------------------------------------------------
>
