----- Original Message ----
From: Daniel Risse <[EMAIL PROTECTED]>
> To get around this, while still not having to specify the number of
> tests to execute, it is run a test from an END block that fails unless
> the test completed. This would be signified by calling a function on
> the last line of the test saying that everything was ok.
I have two minor point, neither of which is all that serious.
Having a test count helps us to know if tests unexpectedly terminate, but it
also lets us know that we have the correct number of tests.
foreach my $foo ( $object->foo ) {
ok looks_like_number($object->$foo),
"... and $foo should be a number";
}
If all of a sudden 'properties' stops returning one of the properties, your
scheme won't catch it. Of course, a good test suite should test that property
explicitly, but 'properties' could also start returning an *extra* property and
there's more of a chance that this won't be tested.
The argument I generally here against stuff like this is something along the
lines of "yeah, but that's a bad way to write tests". This is true because
clearly you want to explicitly test the number of items being returned, but
whether or not someone is writing tests in a good way is orthogonal to whether
or not the Test::Harness will help them spot problems.
Another nice reason for having a test plan up front, and it's something we
can't appreciate since Test::Harness makes it so hard to do: having a progress
bar for tests. Having a top progress bar for the number of test
scripts/classes and a second progress bar for the number of tests within a
given script or class is a much nicer touch than people think. For some
reason, many programmers tremendously underappreciate the value of visual
representations and pretty graphics working in harmony with a test suite are a
plus. Without the test plan, the bottom bar is merely red or green.
Those minor, minor nits aside, I think this is a fine idea.
Cheers,
Ovid
