* 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/>
