Re: TODO Tests
Aristotle Pagaltzis wrote: As a technique, paying attention to how broken code changes, why does it matter that broken code breaks differently? What does this information tell you that might fix code? It means there is a known internal dependency on some other part of the code that is not being tested directly, either itself or the interaction therewith. You want to be alerted when something changes the result of this interaction. This is very reasonable. I believe this is the point where we diverge. The code's busted, why get fussy over how busted it is? You're probably going to rewrite that bit anyway. But, that's a choice. I think the opportunity cost is too high and there's much better things I could be doing with my time. -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, Order of the Stick http://www.giantitp.com/comics/oots0107.html
Re: TODO Tests
* Michael G Schwern [EMAIL PROTECTED] [2008-05-18 05:30]: Aristotle Pagaltzis wrote: As a technique, paying attention to how broken code changes, why does it matter that broken code breaks differently? What does this information tell you that might fix code? It means there is a known internal dependency on some other part of the code that is not being tested directly, either itself or the interaction therewith. You want to be alerted when something changes the result of this interaction. This is very reasonable. I believe this is the point where we diverge. The code's busted, why get fussy over how busted it is? You're probably going to rewrite that bit anyway. You’re not following. 1. There is non-broken code which isn’t being tested directly. 2. There is a test that ensures its correctness, but only indirectly, as part of testing something else. 3. That something else is currently broken, so the test is annotated TODO. End result: if the untested non-broken code breaks, you don’t notice. Arguably, you should write a test that covers the non-broken code directly so you don’t need to care about the TODO’d test. But that may be comparatively hard for a number of conceivable reasons. Ensuring that the TODO continues to break in the expected fashion may well be cheaper than any of the “proper” options and provides similar safety. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: TODO Tests
On Saturday 17 May 2008 20:48:24 Aristotle Pagaltzis wrote:
You’re not following.
1. There is non-broken code which isn’t being tested directly.
2. There is a test that ensures its correctness, but only
indirectly, as part of testing something else.
3. That something else is currently broken, so the test is
annotated TODO.
End result: if the untested non-broken code breaks, you don’t
notice.
Arguably, you should write a test that covers the non-broken code
directly so you don’t need to care about the TODO’d test.
But that may be comparatively hard for a number of conceivable
reasons. Ensuring that the TODO continues to break in the
expected fashion may well be cheaper than any of the “proper”
options and provides similar safety.
There's a lot more maybe in that paragraph than I like. People already have
to modify the TODO test to add whatever kind of positive assertion you
postulate; why is writing a separate test a barrier?
You can already achieve similar results with:
my $do_i_care_flag;
my $result;
{
local $TODO = 'b0rked';
$result = some_behavior();
$do_i_care_flag = !ok( $result, 'This might be b0rked' );
}
if ($do_i_care_flag)
{
is( $result, 'some value i care about',
'... borked in a predictable way anyway' );
}
else
{
pass( '... but I don't care' );
}
You can skip that block if you have no plan.
-- c
