Who's minister of propaganda this week?

[Paul Prescod]

Michael Chermside wrote:
> 
>...
> 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(). 

Your analysis is incomplete in two ways:

1. I don't think it makes sense to speak of writing a unit test for "one
thing calling another". You test the first thing, you test the second
thing and if the second thing depends upon the first then you've
implicitly tested the connection between them.

2. In object oriented programming languages, we can't just test one
function against one input object class and be confident that the code
is correct. There are an infinite number of potential subclasses of
FancyDateObject. Therefore we should NOT depend on testing every single
one of them with foo. We just need to make sure that foo is correct,
that each FancyDateObject is correct and that the communication protocol
between them is well-understood and tested by both.

3. Statically typed languages are absolutely not immune to type errors
for a variety of reasons:

 * Null pointer exceptions are type errors. You've passed the null
object when the code expected some other object. 

 * Almost every statically typed language also has a set of features for
working around the type system (dynamic casts). 

 * Even when the compiler thinks the "type" of your object is correct,
there are a variety of type-related errors you can make such as passing
a negative number where only positive ones are allowed, passing an
gopher: URL where only an http: URL is allowed, passing an absolute
pathname where only a relative pathname is allowed and so forth. If you
try to catch all of these in the static type checking system you wlil
spend more of your life doing conversions than actually coding. *PLUS*
you will need to do the runtime conversion-compatibility checks
YOURSELF!

4. Yes, if you unit test every unit in your program, and do good
coverage testing you WILL catch ever occurrence of some code calling
foo. That's what good testing is about. And you need it, not to catch
the basic type errors but to catch the subtle semantic errors. Catching
the basic type errors comes for free.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.activestate.com/pythoncookbook