"Tom Adams" <tadamsmar / aol.com> wrote in message
news:793af3df.0112101027.1061721f / posting.google.com...
> "Kent Beck" <kentbeck / my-deja.com> wrote in message
news:<9v1ss3$adi$1 / suaar1aa.prod.compuserve.com>...
>
> > (Ken's proposed 5 test case solution to Myers Triangle problem was
here)
>
> 1. What about oddities in the source code? Like:
>
> if (any side ==4) {
>     return 1;
> }
>
> This would cause it to fail for the test case 1,2,4 and your tests
> would miss that.
>
> You would need white-box testing to catch this, or you would need
> more, perhaps many more, black-box tests to cover all the possible
> internals of the function's code.

You're violating the assumption that we're talking about XP. All
production code should be written from the unit tests, so such a
randomly idiotic test shouldn't be in there in the first place. If it
was, the pair should have caught it, and the next person to look
at the function should catch it.

If all of that fails, of course you're right. It won't be caught until
it fails somewhere else, and someone has to debug it.

> 2. There is also the issue of very large integer values.  At least,
you
> can call the function with literal integers where it will fail.
Actually,
> it is not possible to code the function to handle integers of
unbounded
> size without using some special integer representations.  Anyway, a
> function would pass your tests with undefined behaviour for very large
> integers.  And, code using the function could work on one compiler or
> machine and fail on another, depending on the language, because of
issues
> related to integer size.

That actually depends on whether the language allows you to
pass something that the function/method will convert to an integer.
In the stated problem (the Meyers Triangle problem) the only
operations are comparisons, so the problem of integer size
is irrelevant unless you're using something like Perl, which can
take a string and attempt to convert it to an integer to do an
integer comparison.

None of the three implementations I've seen (my rather pedestrian
procedural implementation in Python, RM's implementation or
KB's implementation) has this problem as long as the language
doesn't contain any way of failing on the parameter passing.

Of course, if the problem also said something like:

The user will pass the sides as strings. Distinguish whether
the user input is valid, and whether it constitutes a valid
triangle.

we would need more test cases and code.

John Roth