develooper Front page | perl.perl5.porters | Postings from May 2008

TODO Tests

Thread Next
From:
Bram
Date:
May 5, 2008 11:37
Subject:
TODO Tests
Message ID:
20080505203618.7tbfyrcvj4ook8cw@horde.wizbit.be
While adding the todo tests for t/op/range.t I ran into some  
limitations (IMHO).

Currently the way to define a TODO test is:

{
   local $TODO = "test that foo() returns 1";
   my $s1 = foo();
   is($s1, "1");
}


foo() at the moment returns 3 instead of 1. Which is fine.

Next month, as a side effect of a patch,  foo()  now returns 4.

This is a step in the wrong direction but the tests suite won't pick  
this up, since it still isn't equal to 1.

Or an alternative: next month, as a side effect of a patch,  foo()   
now returns 2.

The test suite won't pick this up either.


Proposal:

Adding some syntax to support (among other things):

   todo_is($value, $value_wanted, $expected_value, $name_of_test);
   (or perhaps: todo_is($value, $value_wanted, $name_of_test,  
$expected_value);)

Or following the example:
   my $s1 = foo();
   todo_is($s1, "1", "3", "test that foo() returns 1");


Now there are three options:

a) $s1 contains 3, no special output is printed
b) $s1 contains 1, output the same as it is now: (basically)  
unexpected pass for todo: "test that foo() returns 1"
c) $s1 contains 2 or 4, output: unexpected output for todo: "test that  
foo() returns 1"


Any opinions on this? (Or better asked: are there reasons against this?)
(Or am I repeating an old idea?)


(todo_is is of course an example. todo_ok, todo_like, .... also need  
to be added)


Kind regards,

Bram



Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About