Who's minister of propaganda this week?

[Doug Hellmann]

On 14 Mar 2001 19:14:21 -0600, Michael Chermside wrote:
> Alex Martelli wrote:
>          ... [snip]...
> 
>   >
>   > So, all the compile-time checking is buying is catching (a small
>   > subset of) the errors that would be caught in testing anyway, a
>   > little bit earlier (thus, a little bit cheaper) -- it's never the
>   > case that one has to write a test which would not be needed at
>   > all if type-checking was static, since "the object has the right
>   > type" is a small subcase of "the object _behaves_ per the specs".
>   >
> I'm really not sure I see it this way. If the method  foo(x) is known to
> take a FancyDateObject
> there are three kinds of errors we could make. One is that foo() is
> written badly so it
> doesn't do what it's supposed to. The unit tests of foo() need to guard
> against this.
> Another possible error is that FancyDateObject isn't written properly.
> The unit tests
> of FancyDateObject need to guard against this. And the third type of
> error is that
> that somewhere where we CALL foo(), we might pass it a DateObject
> instead... or
> even a String... which will cause it to perform wrong. To guard against
> this in a
> dynamically typed language, we have to write unit tests for *every
> single place*
> that we call foo(). Of course, we'd be writing unit tests for those
> functions anyway,
> but we won't be able to assume that foo() works properly, and will need
> extra
> tests to ensure this.

We *can* assume foo() works correctly, because we have already written
unit tests for foo() above. So, when bletch() calls foo() I write tests
of bletch() to verify that *bletch()* works correctly.  If it does not,
it could be because it is using foo() incorrectly, but that is not a bug
in foo().

So we need 3 sets of unit tests ( for foo(), for FancyDateObject, and
for bletch() ) but *unit* tests focus on the unit they are testing.  :-)

Doug