ok 1.2.3 allows this
ok 1.1.1
ok 1.2.1
ok 1.1.2
ok 1.2.2
so if people use the Test::AtRuntime they can also execute those tests at test
time, just allocate subblock 1.* to all the runtime tests. They will appear
in the output, intermixed with all your other tests but they will not
interfere with the correct counting of those other tests.
Also you can allocate a sub block to each thread and you don't have to worry
about it's output getting confused with the output of any other thread
because every thing from thread 1 will have a number starting with 1. and
thread 2 will have 2. etc
You can not do these reliably when you just have extensions
Say thread 1 should print
1..1
ok
1..1
ok
and thread 2 should print
1..1
ok
1..1
ok
The comments are just for our benefit.
You get
1..1 # t 1
1..1 # t 2
ok # t 1
1..1 # t 1
ok # t 2
1..1 # t 2
ok # t 1
ok # t 1
Without the comments there's no way to tell that thread 1 ran 3 tests and
thread 2 only ran 1. Actually this can happen currently now that I think of
it. ok 1.2.3 would catch that.
Even with only a single thread, in order to catch this kind of thing you must
make sure that the plan is not extended before the current plan is finished
which means something like this is illegal
foreach my $person (@big_red_people)
{
plan_more 2;
ok($person->{size} > 10);
is_valid_person($person); # wrong, because it has it's own subplan
ok(person->{colour} eq "red");
}
You have to call is_valid_person() _after_ you test size and colour, otherwise
you won't notice when is_valid_person() overruns by 1 and colur doesn't get
tested at all.
One compromise would be to number the sub plans and have a finish marker that
included the number. That would solve the "was it 2+2 or 1+3?" problem but it
wouldn't solve the threaded situation or the cross-cutting runtime test one
either,
F
