On Wednesday 20 August 2003 11:52, Michael G Schwern wrote:
> I've yet to see a real use-case for plans of plans.
Currently it's impossible to use testing functions and plans without major
headaches. If I do this
sub is_valid_person
{
my $person = shift;
like($person->{Name}, "(Mr|Mrs|Miss) .*? .*?", "name ok")
is_valid_address($person->{Address});
ok($person->{Age} > 0, "age ok");
}
my @people = get_20_of_people;
is_num($#people, 19, "got 20 of them");
foreach my $person (@people)
{
is_valid_person($person);
}
When I write my plan I have to think about how many tests are in
is_valid_person, and in is_valid_address and how many people there will be.
Changing any of these means changing the plan.
Also if I probably won't repeatedly check the validity of a person after every
function. So when I should write
my $person = Person->new;
is_valid_person($person);
$person->change_something;
is($person->{Thing}, "what it should be", "change succeeded");
is_valid_person($person);
$person->change_something_else;
is($person->{OtherThing}, "what it should be", "other change succeeded");
is_valid_person($person);
So every time I do something to a person object I should check that everything
about that person is still valid but doing that and maintaining a plan is a
pain.
I'd also like to be able to do this in my fictional database cacher
use Cache::Cache::Tests;
sub is_valid_dbcache
{
my $dbcache = shift;
is($dbcache->{This}, "that");
etc etc.
Cache::Cache::Tests::is_valid_cache($dbcache->{Cache});
}
> It also causes problems with the real use-cases of forking and running
> a test program from a test program. That cannot be ignored.
How does this work at the moment? If 2 forks from a single process are both
running tests then they currently mix their numbers up so currently forking
and correct numbering are incompatible. Things are no worse with blocks, just
don't use them. Although they could be better with blocks.
It should be possible to tell fork 1 to use block 1 (and not finalise block 2)
and fork 2 to use block 2 (and not finalise block 1), in which case forked
scripts could properly number their tests. It's extra work to implement this
and maybe it's not worth it but if it was implemented forked scripts would be
even nicer than they are now.
> Work under the assumption that each subplan is not aware of the state
> of the overall test. This will produce the most useful protocol.
In the scheme mentioned, the only thing the sub-plan is aware of is it's
name/number, they don't know or care about the progress of any other blocks,
all they know is that any tests run as part of this plan should have the
number prepended to them and when it's finished it should output a comment
perhaps or maybe a test result indicate if the plan was adhered to,
F
