On Wednesday, August 20, 2003, at 11:52 am, Michael G Schwern wrote: [snip]
I've yet to see a real use-case for plans of plans.[snip]
Anywhere when you want to have plans at a higher level of granularity than a test script.
For example in Test::Class I can say:
sub pig_flying : Test(2) {
my $self = shift;
lives_ok {$self->{live_pig}->fly} 'live pig does fly';
dies_ok {$self->{dead_pig}->fly} 'dead pig does not fly';
};I want to know that only two tests run. At the moment I have to do the bookkeeping on the number of tests run internally within Test::Class. It would be nice if T::H could do this for me.
I also have to figure out a way of reporting incorrect sub-plans to the test runner. At the moment I do this by reporting a failing test. This, to me, is incorrect since it is a problem with the test script, rather than the thing we are testing. It should be something T::H can deduce - just like it can figure out an incorrect plan at the script level.
Direct support for nested plans in the T::H protocol are not the only solution. With some more developer work you could also do it using the extending test plan idea that somebody (Andy Lester?) mentioned a few months back. But I can see places where nested plans could be useful.
Adrian
