Test cases and static typing (was: Python from Wise Guy's Viewpoint)

[Dirk Thierbach]

Pascal Costanza <costanza at web.de> wrote:
> Remi Vanicat wrote:

>>>>> In a statically typed language, when I write a test case that
>>>>> calls a specific method, I need to write at least one class that
>>>>> implements at least that method, otherwise the code won't
>>>>> compile.

>>>>Not in ocaml.
>>>>ocaml is statically typed.

>> It make the verification when you call the test. I explain :
>> let f x = x #foo
>> 
>> which is a function taking an object x and calling its method
>> foo, even if there is no class having such a method.
>> 
>> When sometime latter you do a :
>> 
>> f bar
>> 
>> then, and only then the compiler verify that the bar object have a foo
>> method.

BTW, the same thing is true for any language with type inference.  In
Haskell, there are to methods and objects. But to test a function, you
can write

test_func f = if (f 1 == 1) && (f 2 == 42) then "ok" else "fail"

The compiler will infer that test_func has type

test_func :: (Integer -> Integer) -> String

(I am cheating a bit, because actually it will infer a more general type),
so you can use it to test any function of type Integer->Integer, regardless
if you have written it already or not.

> Doesn't this mean that the occurence of such compile-time errors is only 
> delayed, in the sense that when the test suite grows the compiler starts 
> to issue type errors?

As long as you parameterize over the functions (or objects) you want to
test, there'll be no compile-time errors. That's what functioncal 
programming and type inference are good for: You can abstract everything
away just by making it an argument. And you should know that, since
you say that you know what modern type-systems can do.


But the whole case is moot anyway, IMHO: You write the tests because
you want them to fail until you have written the correct code that
makes them pass, and it is not acceptable (especially if you're doing
XP) to continue as long as you have failing tests. You have to do the
minimal edit to make all the tests pass *right now*, not later on.

It's the same with compile-time type errors. The only difference is
that they happen at compile-time, not at test-suite run-time, but the
necessary reaction is the same: Fix your code so that all tests (or
the compiler-generated type "tests") pass. Then continue with the next
step. 

I really don't see why one should be annoying to you, and you strongly
prefer the other. They're really just the same thing. Just imagine
that you run your test suite automatically when you compile your
program.

- Dirk