From: rmoldskr@...
Date: 2001-12-08T18:16:11+09:00
Subject: [ruby-talk:27910] Re: A challenge to proponents of Unit Testing.

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?

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?

[SNIP]
-- 
Leif Roar Moldskred