From: David B Lightstone <david.lightstone@...>
Date: 2001-12-15T23:30:58+09:00
Subject: [ruby-talk:28618] Re: John Roth dolt (  Re: A challenge to proponents of Unit Testing. )


"Ron Jeffries" <ronjeffries@REMOVEacm.org> wrote in message
news:DB65EEFC6EC408D5.2EDCBB2794B0E67A.2215488CA88D652F@lp.airnews.net...
> 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.
>
> We seem to be talking about two different things here or something.
>
> The original concern was about why we don't push coverage tools. (As I
> mentioned elsewhere, many teams do use them. XP does not in general
> push tools or techniques at that level: we trust and expect that
> people will use them if they are needed.)
>
> Coverage tools are not needed in general, I suggest, because teams can
> ship with low enough defect counts without them. If defects are not
> being detected downstream (that is, by testing outside the team or by
> users), then things are fine as they are. When defects are detected
> outside the team, then the team reflects on what happened and improves
> their process. The outcome is usually improvements to the programmer
> and customer test nets, and a better understanding of how to write
> tests. The outcome is often other process improvement, such as
> improved coding standards, coding tools, or testing tools (such as
> coverage).
>
> My point was that the driving element isn't coverage, it is defects.
> If too many are detected beyond the team, the team needs to improve
> its process. That process improvement might be to add coverage
> analysis. In my experience that's not one of the earliest choices
> made, and many teams deliver satisfactory quality without ever going
> there.
>
> Does that clarify what I was saying? Please recast your comment in
> that light so that I can respond better. Thanks,

I think your answer is -
We improve the testing net when a defect is observed in the field



<snip>