2009/3/16 Michael G Schwern <schw...@pobox.com>:
> Fergal Daly wrote:
>> Alternatively, the plan is a meta-test, a test for your testing code.
>> It is the equivalent of putting
>>
>> is($tests_run_count, $tests_i_planned_count)
>>
>> at the end of your test script. Letting the computer calculate the
>> plan is the equivalent of putting
>>
>> is($tests_run_count, $tests_run_count)
>>
>> at the end of the your test script. It's pointless. It will always pass.
>
> I hear where you're coming from, but there is some value in knowing a test
> still does what it did before. A regression test.
>
> Consider the following:
>
> my @things = $obj->things(3);
> for my $thing (@things) {
> is $thing, 42;
> }
>
> It's nice to know that things() still returns 3 items. Yes, there should be a
> test in there checking that @things == 3 but maybe there's not and this is a
> simple example.
This is exactly what a plan will catch and why it can't be automated.
As far as I can tell we're agreeing.
> That said, I'm not fond of those folks with editor macros to set the count to
> whatever number just ran. Seems too easy to abuse.
This is not unreasonable if you have an RCS, particularly if you do
code reviews of each others checkins because then you're likely to
notice how the plan is changing (or not) with each checkin. Otherwise
you're just wasting CPU cycles and should use no_plan,
F
>
> --
> "Clutter and overload are not an attribute of information,
> they are failures of design"
> -- Edward Tufte
>
