<lrm / provida.no> wrote in message
news:lT7Q7.9614$yB2.158772 / news1.oke.nextra.no...
> In comp.object John Roth <johnroth / ameritech.net> wrote:
>
> > Let's think about this for a moment. 5 test cases appears to
> > be adequate for a black box test. You need one for equilateral,
> > three for isosceles and one for scalene. If you're deriving
> > more test cases, you're doing an open box test, based on the
> > actual implementation (or on some set of assumptions about
> > frequent defects, or some such.)
>
> How about bad data? Won't you need tests to ensure that the code can
> handle bad (zero or negative) values for any combination of the sides?
> Isn't that 7 more tests (illegal data for: {a, b, c, a & b, a & c, b &
> c, a & b & c })?
>
> --
> Leif Roar Moldskred

The specification did not say: test for bad data and return
an exception (or whatever). If the specification said that,
you would need three additional tests, one for each
of a, b, c not being positive. (The cases are independent.)
It also didn't say what you should do in that case. If
you were firewalling the code against invalid data
created by another function that shouldn't be doing it,
then the implementation should be an assertion. If the
function can be called from user code without additional
checking, then more needs to be done, but that needs
to be specified. Otherwise, you're violating the
injunction against doing more than you are asked.

Of course, it's your right to say that the specification
doesn't make sense as written, and get it changed
by the customer.

Even if you're testing for invalid data, most testing
theorists would suggest separate tests for zero and
negative, on the perfectly reasonable grounds that
bugs are likely to hide here. However, that's making
an assumption about the implementation.

John Roth