----- Original Message ----
From: Adam Kennedy <[EMAIL PROTECTED]>
> What I find surprising is the concept that a TODO test is assumed to fail.
>
> If I mark a test (block) as TODO, I would have thought by flagging some
> tests as not done yet then for the purposes of PASS/FAIL I don't care
> what the result it.
As a test author, you may not care, but as someone using your code, I most
assuredly DO care. Consider:
my $object = Object->new;
# do a bunch of stuff
$object->store;
Now imagine that the code blows up when I try to store the object. If I only
use features that are listed as 'OK' by the test suite, I should presume that
they not leave the object in some sort of inconsistent state that store() fails
on. If TODO tests mark a complete feature and some parts of that feature pass
but I don't notice that they've unexpectedly succeeded, I have no way of really
trusting what state they'll leave my object in. Thus, I can't trust TODO tests.
This is why we normalize databases and use transactions: to make it impossible
(in theory) to leave the database in an inconsistent state.
Let's look at something concrete:
TODO: {
local $TODO = 'We do not have anti-gravity drives';
can_ok $spachship, 'engage_anti_grativity';
ok $spaceship->engage_anti_gravity,
'We can use anti-gravity';
ok $spaceship->is_floating,
'The spaceship is floating'
}
And if someone wrote the following stub:
sub engage_anti_gravity { 1 }
Then under the current Test::Harness behavior, that would be reported as a
success, the first two tests would be reported as success.
And the developer sees that engage_anti_gravity() passed so she writes:
$spaceship->engage_anti_gravity;
And everybody dies.
That would be disappointing.
One could argue that the stub shouldn't have been written, but such things get
written all the time. One could argue that the developer should notice the
subsequent TODO test failed, but that's not always going to happen (or that
subsequent TODO test might not have been written). I would argue that a test
suite should make these sorts of issues easier to spot.
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
