[Distutils] red, green, refactor OR red, green, new feature?

[Ben Finney]

Thomas Güttler <guettliml at thomas-guettler.de> writes:

> Hi distutils friends,
>
> which workflow do you prefer?
>
>  1. red (test fails)
>  2. green (test and code works)
>  3. refactor (clean up, deprecate old stuff)

More accurately:

  * Write a failing test for the new behaviour. (red)
  * Change the system-under-test until the test passes. (green)
  * Clean up, remove redundancies, change no behaviour (refactor)

> OR

I disagree with that dichotomy.

>  1. red
>  2. green
>  3. new feature.

The latter isn't a workflow I recognise. It appears to confuse the
levels of working.

Making a new feature is much higher level than the rest of those steps;
it entails many iterations of “red, green, refactor”.

> I, like most other programmers, love new features

You're thinking that is incompatible with test-driven development.
Actually, from the TDD point of view, adding new features is like any
other change to the system under test: follow the TDD workflow (red,
green, refactor) until the new feature works.

> Are you willing to clean up and deprecate old stuff?

Everyone who works with code should be *willing* to do it. What TDD does
is allow the programer to do that with confidence.

-- 
 \        “Intellectual property is to the 21st century what the slave |
  `\                              trade was to the 16th.” —David Mertz |
_o__)                                                                  |
Ben Finney