Robert C. Martin <rmartin @ objectmentor . com> wrote in message news:<h2n41ucnnc8ipnseets4eess8rbqehkes6 / 4ax.com>...
> On Sat, 08 Dec 2001 00:35:43 -0600, Robert C. Martin <rmartin @
> objectmentor . com> wrote:
> 
> >On 7 Dec 2001 02:04:08 -0800, stephen.hill / motorola.com (Steve Hill)
> >wrote:
> >
> >>What tests would you write for a function that takes 3 numbers (the
> >>side lengths of a triangle) , and returns whether the triangle is
> >>equilateral, scalene or isoceles.
> >
> >Set<int> sides; // data structure allows no duplicates.
> >sides.add(a);
> >sides.add(b);
> >sides.add(c);
> >return sides.length(); // 1 = equilateral, 2=isoceles, 3=scalene.
>           ^^^^^^^^^--oops.
> >
> >What am I missing?

In this example, wouldn't using an int set for the sides prevent
representing any triangle with two or more equal lengths -- I think a
bag would do the job. Assuming that your set would reject identical
values, any test suite which did not include tests like 3,3,4 or 3,3,3
would miss that bug.

What are the bounds of the ints?  If this the typical signed int, zero
and negative values are allowed. Should I take it on faith that the
implementation will reject values less than or equal zero? (granted,
if you have the code in front of you, an inspection would probably
suffice to answer that question.)  I see nothing in the interface
definition to warrant such confidence, however.  If you'd defined a
bag of natural numbers (not ints), I would be willing to take it on
faith.

A typical algorithm for clasifying the lengths as a triangle sums the
lengths.  Using the maximum value for at least one int (e.g.
(2**32)-1) will usually cause an arithmetic overflow.

Another common bug is to classify the lengths based on only checking
two sides -- this is why Myers insisted on permuting the sides for
each type.

All of this is listed on page 7 of my book.   

Your example is much closer to Myers' original three numbers on a
punched card problem than the class hierarchy I used to highlight the
differences of testing oo and procedural implementations, which
include complex data types, inheritance, and polymorphism. The larger
number of tests in my example (65) are a direct result of that stuff,
but are only a first stab to suggest the kind of problems in finding
bugs in oo implementations.

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".


___________________________________________________________________ 
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