On 12/21/05, Steve Litt <slitt / earthlink.net> wrote:
> On Wednesday 21 December 2005 07:20 pm, Eero Saynatkari wrote:
> > Joe Van Dyk wrote:
> > > I've found that when I write the tests first, and then write
> > > the code, I'm not very concerned about what the code looks
> > > like.  When the code passes the test, I drink a beer and party,
> > > then move on to the next test.
> > >
> > > In practice, this means that I'm using a lot of ugly regex's,
> > > poorly named variables, and so on.  I'd be more concerned about
> > > the readability of the code if there wasn't unit tests behind
> > > it.  I'm generally in a rush to finish whatever I'm doing, and
> > > figure that since I have a bunch of tests, refactoring stuff
> > > later won't be a big deal.
> > >
> > > Anyone else out there like me?  Or should I be anal about
> > > writing good code even with the tests?  I guess that would be
> > > ideal, but I'd rather get the functionality done first.
> >
> > This is the whole 'design after' or 'refactoring' paradigm:
> > make it work, then implement a proper design and prettify.
> > Passing unit tests prove that nothing was broken :)
>
> I cannot in a million years imagine coding without design. I've
> never coded tests first (I test each class after coding it), but I
> can't imagine why writing the tests first would make one not
> design. If it did make me not design, I wouldn't code test first --
> I'd make test jigs after.

Oh, I spend a lot of time on class designs (and how the various
objects interact with each other).  I tend to follow the 'tracer
bullet' philosphy outline in the pragprog books.

It's just that, within the beautifully designed functions and classes,
lies unspeakable monsters.  (ok, maybe not that bad)