Subj : Re: Not debugging?
To   : comp.programming,comp.lang.java.programmer,comp.lang.lisp
From : Phlip
Date : Thu Aug 25 2005 02:24 am

Russell Shaw wrote:

>> No. I'm talking about developers who don't write unit tests as they write 
>> code. These provide the option of using Undo, instead of debugging, when 
>> the tests fail unexpectedly.

> You can only write tests before the code if you are very familiar with 
> what
> you want and have thought about it for hours/days/weeks.

We ain't talking about white-box acceptance tests.

If you can think of the next _line_ of code to write, you must perforce be 
able to think of a complementing test case that would fail if the line were 
not there. Just make writing the test case part of writing that line.

> In the process of
> making the solution of a very tedious problem clear to me, i can do a 
> *lot* of
> throwing away of code and refactoring for weeks at a time.

That's not "refactoring" it's "rework". But it's okay - more below.

> The amount of extra
> churn from rewriting unit tests would be hopeless.

There are two forks to the answer to this.

One fork: Those tests support you because they should _decouple_ from the 
tested code. After you have that line, you can move it around (_that's_ 
refactoring), screw with it, rewrite it, etc. The tests _support_ this 
noodling around, when you run them over and over again. If a test fails 
unexpectedly, you use Undo until it passes, then try another change.

> Refactoring of code *is* my
> thought process. Write code that works, then write unit tests to make sure 
> it
> keeps working. Gdb/ddd is indispensible.

Here's the other fork of the answer:

Software Engineering is 99% inspiration and 1% perspiration. Harnessing any 
kind of creativity is priceless. Until you learn TDD enough to use it 
creatively, you might like to work out designs and algorithms using 
code-and-fix (or UML diagrams, or Tarot cards, or LSD, or NBC, or whatever).

When you like a solution, now convert it into robust coding by using TDD to 
recreate it. If you already know the code's behaviors and design, you must 
perforce be able to think of a series of test cases that will force the code 
to reappear in your production codebase.

While I find TDD for creativity very useful, TDD to reconstitute an existing 
module is as easy as falling off a log.

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

.