"Bob Binder" <rbinder / rbsc.com> wrote in message
news:ded6b237.0112120608.6d0e916a / posting.google.com...
> rbinder / rbsc.com (Bob Binder) wrote in message
news:<ded6b237.0112110655.6e944974 / posting.google.com>...
> > Keith Ray <k1e2i3t4h5r6a7y / 1m2a3c4.5c6o7m> wrote in message
news:<k1e2i3t4h5r6a7y-7C2620.18082110122001 / news.attbi.com>...
> > > In article <ded6b237.0112100935.57024f11 / posting.google.com>,
> > >  rbinder / rbsc.com (Bob Binder) wrote:
> > >
> > > > BTW, the apparent meaning of "adequate testing" in this thread
is not
> > > > consistent with definition used in the testing community for
over 15
> > > > years: adequate testing must *at least* achieve statement
coverage.
> > > > There are many other possible definitions of "adequate testing",
but
> > > > if your tests don't at least reach all the code in the IUT, you
can't
> > > > claim to be doing adequate testing. Although any definition of
> > > > "adequate testing" which attempts a more stringent criteria can
be
> > > > falsified, many unambiguous non-subjective criteria for adequacy
have
> > > > been useful in practice, but they don't include "I say so".
> > >
> > > Didn't the tests in the examples by Kent and Uncle Bob have 100%
> > > statement coverage, so by your definition, they are "adequate"?
>
> On further reflection, I'd agree that the proposed test suites achieve
> statement coverage for the example code.  The examples have no
> selection or iteration, so any single test will do the job. This
> provides a good example of why statement coverage is a necessary but
> not a sufficient condition for adequate testing.

> In typical situations with lots of branching and iteration, the tests
> needed to achieve statement coverage are not obvious, hence the need
> for a coverage analyzer to determine that statement coverage (better
> yet branch) has been actually been achieved.

If you feel it's important, (and I certainly do) coverage analyzers can
be added to the XP procedures quite simply, as long as they are
fast and automated. If I was going to add one, I'd probably make
100% coverage a criterion for code checkin, just like the 100%  unit
tests successful criterion.

John Roth

>
> _________________________________________________________________
> Bob Binder           http://www.rbsc.com      RBSC Corporation
> rbinder@ r b s c.com Advanced Test Automation 3 First National Plz
> 312 214-3280  tel    Process Improvement      Suite 1400
> 312 214-3110  fax    Test Outsourcing         Chicago, IL 60602