From: Ron Jeffries <ronjeffries@...>
Date: 2001-12-15T22:10:50+09:00
Subject: [ruby-talk:28612] Re: John Roth dolt (  Re: A challenge to proponents of Unit Testing. )

On Sat, 15 Dec 2001 01:04:18 GMT, "David B Lightstone"
<david.lightstone@prodigy.net> wrote:

>> >I mostly agree with this, and it bothers me that XP advocates don't seem
>> >to pay much attention to coverage tools.
>>
>> The short reason, and I don't mean it to be curt, is that we are
>> paying attention to defect detections, not to coverage. When defects
>> slip through the net, we improve the net.
>
>Don't you kind of have a chicken and an egg situation here. Can't
>observe a defect that slips thru the net without either conducting
>an observation (aka test) or doing a code analysis. As near as I
>can tell analysis only occurs when a defect is detected or
>someone declares a need for a refactoring.

In reading our discussion, it occurs to me that some people might
accidentally move beyond the simple discussion of whether and when
coverage tools are needed, which is what we are mostly talking about
above. 

There certainly are other quality issues in software besides defect
removal. Here are a few that come to mind, with a quick word or two
about where they come from:

Defect prevention is certainly more important than removal. XP defect
prevention practices include
  - pair programming, which ensures at least one other programmer has
reviewed all production code.
  - collective code ownership, which results in more than one other
programmer reviewing most of the production code, as different pairs
work on it.
  - insistence on automated programmer and customer tests, which catch
regressions and other inserted defects before they get released.
  - small releases, which get the software in the hands of users
early. These early users often do detect errors, which feed back into
the customer and programming testing process, improving it at the
early stages. The team learns how to test better and how to write the
software better.

Other quality emphases that are present but were not germane to the
testing discussion include more subjective matters such as
flexibility, extensibility, and robustness.

Keep in mind that XP, like any incremental development method,
reaching at least as far back as Boehm's Spiral Model, relies on
continuous improvement of the code base. 

In the case of XP, any problems in these "ilities" will be evidenced
by difficulty in adding new features. If the team has problems in
these areas, they will quickly find out, since the development is
incremental. 

XPers practice continuous design improvement through refactoring. The
code is kept simple, i.e. modular in the sense of Constantine et al:
high cohesion and low coupling.

It is modular code that produces flexibility, extensibility, and
robustness. This has been understood since at least the 1960s and was
the primary impetus behind the "structured revolution" in the 70's and
80's. Refactoring is the tool incremental developers have always used
to evolve the code while maintaining good design: it's just that now
it has a name.

XP concerns itself with much more than defect discovery or prevention.
That's why there are a dozen practices, not just one. 

Probably most of us here remember and consider the whole context: I
just wanted to bring it out in case there was anyone here who didn't
know, or had forgotten.

Thanks,


Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com