From: David B Lightstone <david.lightstone@...>
Date: 2001-12-09T00:17:10+09:00
Subject: [ruby-talk:27941] Re: A challenge to proponents of Unit Testing.


"John Roth" <johnroth@ameritech.net> wrote in message
news:u149pbf6or7p63@news.supernews.com...
>
> <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.

This is probably the key to understanding the whole argument
There are 2 separate problems being addressed. Nobody
can sort out which problem is being addressed at a given time
Some assume - internal routine others assume external.

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