From: rbinder@... (Bob Binder) Date: 2001-12-11T02:39:56+09:00 Subject: [ruby-talk:28111] Re: John Roth dolt ( Re: A challenge to proponents of Unit Testing. ) Robert C. Martin wrote in message news:... > On Sat, 08 Dec 2001 00:35:43 -0600, Robert C. Martin 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 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