Subj : Re: Not debugging?
To   : comp.programming,comp.lang.java.programmer,comp.lang.lisp
From : Phlip
Date : Fri Aug 26 2005 06:03 am

George Neuner wrote:

> In principle you're right ... but it's rarely that simple.

Yes it is. You are considering the harder task of retrofitting 
acceptance-level tests to the outside of finished APIs. Not the simpler and 
more direct task of writing tests that fail so you can write a line or two 
of behavior to pass them.

> I support testing and assertions wherever possible, including
> intra-procedure if there is some meaningful test that can be done on a
> partial result - but testing line by line is ridiculous.  It may be
> extremely difficult or quite impossible to figure out what would
> happen if a particular line of code is wrong or missing.

That's why you run the test and ensure it fails for the correct reason, 
before writing the code to pass the test. The test doesn't have to be 
exact - it doesn't need to constrain your code to only one possible new line 
[or two]. You write more tests until all of them constrain.

> It's also
> unwieldy because such tests frequently can't be batched but must be
> executed in-line due to following code altering the test conditions.

Design-for-testing implies you have just a little more API, and you use it 
to detect these intermediate states. The requirement to write tests first 
makes such API adjustments easier.

> I didn't agree with this "line by line proof" approach in 1981 when
> Gries proposed it in "The Science of Programming" and I don't agree
> with it now.  YMMV.

That was probably something different, and TDD is not a "proof" system.

> I use to do image processing in which the processing was a dependent
> chain of fuzzy logic.  All the possible answers were wrong in some
> absolute sense - and the object was to find the answer that was least
> wrong.  If I missed a minor step or had a bug in a calculation
> somewhere, the chances are I wouldn't be able to tell by looking at
> the intermediate results.

Right. Such tests can be very fragile and hyperactive. Hence, run them 
_more_ often, and if they fail unexpectedly use Undo to back out your 
change, then think of a smaller change that doesn't change an irrelevant 
side-effect. Tests that constrain too much are better than ones you run 
infrequently.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

.