<rmoldskr / online.no> wrote in message
news:QEkQ7.10066$yB2.163125 / news1.oke.nextra.no...
> In comp.object John Roth <johnroth / ameritech.net> wrote:
>
>
> > The specification did not say: test for bad data and return
> > an exception (or whatever).
>
> But then this behaviour is undefined - and that can't be a good thing,
> can it?
>
> > 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.)
>
> But doesn't the assumption that the cases are independant break the
> black box? How do you know that it's enough to check the three cases
> where just one of the sides have illegal values without knowing or
> making assumptions about the implementation?
>
> > 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.
>
> But doesn't focusing on testing the specification mean that you might
> overlook vagueness in the specification and with that undefined
> behaviour in the product?

It's always possible to overlook vagueness in the specification,
however, that's what inspections and so forth are for. If you
discover that the specification is too vague for you, by all means
bring the issue up to whoever wrote it. You may or may not
be right, but going off on your own is always wrong.

> If nobody realizes that the specification doesn't cover a value that
> might arise in a real deployment, then you're not going to discover
> that as you are always only testing the by the specification. Or am I
> misunderstanding something?

No, you're not missing something. I made a distinction between
an internal and external routine for a reason. An internal routine is
one that can trust its callers to pass only valid values, an external
routine is one that needs to edit its inputs for validity.

To bring this back to XP, there's a basic misunderstanding of the
function of unit tests in XP. In normal development, unit tests
are created to test an implementation. In XP, they are to
test a specification, and then the implementation is written to
that specification. It takes some experiance to understand that
if you put something in the implementation that is not covered
by the unit tests you've just written, you've made a mistake.

If you feel that you need to test for invalid values, then, after
discussing it with your pair, and you agree that it is reasonable,
then you rewrite the specification. Then you write the necessary
unit tests.


John Roth