TDD and refactoring

I know pretty much nothing about TDD but am starting to read about it
and one thing struck me early on.
You write the simplest test and then do the minimal amount to make it
work (or the test that describes the essence of what you are trying to
accomplish but thats later).

Then you write the next one, refactoring to make this one work and so on.
You might easily refactor the same code twice/thrice etc.

It would be very tempting to anticipate your tests and code ahead to
minimise refactoring.

Is this to be avoided at any cost or do people do this once they become
familiar with the design principles?

BTW: I have not "got" TDD yet so if this is completely irrelevant or
will be illustrated later, feel free to inform me :)

Cheers
JB

gunslinger wrote:
> I know pretty much nothing about TDD but am starting to read about it
> and one thing struck me early on.
> You write the simplest test and then do the minimal amount to make it
> work (or the test that describes the essence of what you are trying to
> accomplish but thats later).
>
> Then you write the next one, refactoring to make this one work and so on.
> You might easily refactor the same code twice/thrice etc.
>
> It would be very tempting to anticipate your tests and code ahead to
> minimise refactoring.
>
> Is this to be avoided at any cost or do people do this once they become
> familiar with the design principles?

Its usually better to avoid it at any cost. Even when you have been
TDDing for a long time and have 'got it' you'll still want to jump
ahead. And eventually that jumping ahead will bite you.

However, even if you do take bigger steps rather than the usual
teeny-tiny steps you describe, the teenytiny step way of working is
still there for 'when' you get bitten.

One point, if your tests run quickly (as in less than a few seconds)
then the temptation to take bigger steps usually isn't felt as you
develop quickly enough anyway.

>
> BTW: I have not "got" TDD yet so if this is completely irrelevant or
> will be illustrated later, feel free to inform me :)
>
> Cheers
> JB

gunslinger wrote:

> I know pretty much nothing about TDD but am starting to read about it
> and one thing struck me early on.
> You write the simplest test and then do the minimal amount to make it
> work (or the test that describes the essence of what you are trying to
> accomplish but thats later).
>
> Then you write the next one, refactoring to make this one work and so on.
> You might easily refactor the same code twice/thrice etc.
>
> It would be very tempting to anticipate your tests and code ahead to
> minimise refactoring.

Absolutely. Whatever you anticipate, you can write a test that leads your
design in that direction.

Even if you don't anticipate, lots of small refactors make the odds of a big
refactor very low. Following the rules, your design will stop changing
sooner than you could have guessed it would.

> Is this to be avoided at any cost or do people do this once they become
> familiar with the design principles?

Refactoring is not bad. It's the design step, in miniature.

Let's express this in terms of safety. Designing on a whiteboard, a long
time before implementing, is unsafe because it lacks feedback. You could
decide on a more complex design than you need. A design that's complex, but
scattered throughout lots of classes, is hard to refactor to simplify.

Or, you could write lots of code, and tests, and only then design (refactor)
after they all work. This has the same problem in reverse - the code is
poorly designed, and there's lots of it.

So, design very close to implementation. Start with a clean design, and add
a little code. But you can't change that design until you have passing
tests, so only write code so simple that the tests pass. When they make
refactoring (designing) safe, it is now as safe as it can ever be. You have
tests on all the well-designed features, plus one. Your new test must still
pass, while you refactor and invest your new code into your old code.

The goal is so few edits between passing tests that you could back out your
edits manually, without using Undo.

> BTW: I have not "got" TDD yet so if this is completely irrelevant or
> will be illustrated later, feel free to inform me :)

Dig in:

http://flea.sourceforge.net/TDD_in_a_nut_shell.pdf

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

gunslinger wrote:
> I know pretty much nothing about TDD but am starting to read about it
> and one thing struck me early on.
> You write the simplest test and then do the minimal amount to make it
> work (or the test that describes the essence of what you are trying to
> accomplish but thats later).
>
> Then you write the next one, refactoring to make this one work and so on.
> You might easily refactor the same code twice/thrice etc.
>
> It would be very tempting to anticipate your tests and code ahead to
> minimise refactoring.
>
> Is this to be avoided at any cost or do people do this once they become
> familiar with the design principles?
>
> BTW: I have not "got" TDD yet so if this is completely irrelevant or
> will be illustrated later, feel free to inform me :)
>
> Cheers
> JB

One more point, in addition to the other replies.

'Refactoring' is not bad. If you are doing the
simplest thing that could possibly work, and using
automated tests, most of the changes you make as
you refactor will be detail changes. They won't
be the kind of wholesale 'cruft removal' that we
typically need to do on existing codebases.

The cruft won't be there in the first place.

gunslinger wrote:
> I know pretty much nothing about TDD but am starting to read about it
> and one thing struck me early on.
> You write the simplest test and then do the minimal amount to make it
> work (or the test that describes the essence of what you are trying to
> accomplish but thats later).
>
> Then you write the next one, refactoring to make this one work and so on.
> You might easily refactor the same code twice/thrice etc.
>
> It would be very tempting to anticipate your tests and code ahead to
> minimise refactoring.
>
> Is this to be avoided at any cost or do people do this once they become
> familiar with the design principles?
>
> BTW: I have not "got" TDD yet so if this is completely irrelevant or
> will be illustrated later, feel free to inform me :)
>
> Cheers
> JB
Many thanks to all.

Good read thanks Phlip

JB
:)

On Tue, 05 Apr 2005 09:40:58 +1000, gunslinger <jbngspam@yahoo.com>
wrote:

>I know pretty much nothing about TDD but am starting to read about it
>and one thing struck me early on.
>You write the simplest test and then do the minimal amount to make it
>work (or the test that describes the essence of what you are trying to
>accomplish but thats later).
>
>Then you write the next one, refactoring to make this one work and so on.
>You might easily refactor the same code twice/thrice etc.
>
>It would be very tempting to anticipate your tests and code ahead to
>minimise refactoring.

Yes, it would.

>Is this to be avoided at any cost or do people do this once they become
>familiar with the design principles?

I use a simple metric.  If I find myself using a debugger, it means
that I have anticipated too much, and I start anticipating less.

As a result of applying that metric I have found that I anticipate
very, very, little.
>
>BTW: I have not "got" TDD yet so if this is completely irrelevant or
>will be illustrated later, feel free to inform me :)

It's remarkably relevant.  It is a question that many senior people
(including myself) continue to reflect upon.


-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

gunslinger wrote:
> It would be very tempting to anticipate your tests and code ahead to
> minimise refactoring.

I experimented with this a while ago. And it does seem to have an
effect on the code you produce.

Testing one test at a time (and writing code to pass only the test you
have written) you:
* make more mistakes
* spend more time refactoring
* produce less code
* have more confidence in the code produced

Code produced this way is descriptive at the lowest level but not so
descriptive in context of the whole problem. Additional refactoring
could probably correct that.

Whereas writing all the tests up front you:
* make less mistakes (this surprised me)
* spend less time refactoring
* produce more code
* have less confidence in the code produced

Code produced this way is more descriptive in the problem context but
contains more duplication which could probably be removed with
additional refactoring.

My experiments were not really big enough to tell if there was any
overall time advantage in either approach. But in either case after
additional refactoring they would probably end up similar, if not
identical.