From: Phlip <phlip_cpp@...>
Date: 2001-11-27T13:47:56+09:00
Subject: [ruby-talk:26613] Turn the knobs up [Was: Ruby vs. Python: Decisions, Decisions]

MikkelFJ wrote:

> I just don't like to let the testcode drive my design -
> it seems like the robot finding the way in a maze by turning left each
> time it bumps into a wall. I'd rather try to get a birds perspective.

The best explanation for it is simple: The kinds of adjustments code must 
make to submit to testing are invariably those that decrease coupling, 
increase cohesion, and experience re-use.

The bird's eye view comes from culling & refactoring, and from reading the 
tests to witness the interfaces in action.

> Not sure whether you're being serious or joking here ("design is hard so
> do it last"). It sounds like speeding so you have less time on the road
> where you can be exposed to an accident.

There are those who drive so danged slow I have developed this diatribe to 
get the point across in a way most likely to offend them and chase them 
away:

Traditional development - WaterFall, spiral, whatever - pretends to differ 
but are really fixated on an unstated unfounded assumption:

        analyze -> design -> code -> test

Spiral just does those in little phases instead of big ones.

You-know-what does this:

        test -> code -> design -> analyze

In that order, it's easy. You read your requirements and express them as a 
test. Easy. Then you back up the test with code that makes it pass. Easy. 
Then you look at live code (NOT a ton of UML), and see the latent design in 
it. Easy. Then you modularize your live systems. Easy.

> Depending on your level of skill, it may be an issue with these tiny bugs
> that amount to a whole population at the time the implementation is
> complete. On the other hand I've seen some very skilled developers produce
> very few bugs and yet come out with design flaws that had to be fixed at
> later stage thus impacting code written by several other people. Such
> problems are unavoidable but they are important to reduce. This is not the
> kind of problems that a test first approach would have helped you to
> eliminate. 

I have done the Pet Bug thing, and I have done the "rolling a ball of bugs 
waiting to be fixed uphill in front of me" thing. I did them because I 
could - because I'm prolifically creative and capable of dealing with 
complexity. But, at the time, I did not understand how I could channel 
these skills productively & stay safely at that high rate.

> So there is nothing wrong with testing often, but the risc is
> that it makes you believe you have a sound design because the test is
> working.

Yep.

-- 
Phlip

http://www.greencheese.org/HatTrick