Test cases and static typing

[Pascal Costanza]

Dirk Thierbach wrote:
> 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.

OK, I have got it. No, that's not what I want. What I want is:

testxyz obj = (concretemethod obj == 42)

Does the code compile as long as concretemethod doesn't exist?

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

Yes, I know that. I have misunderstood the claim. Does the code I 
propose above work?

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

The type system might test too many cases.

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

I don't compile my programs. Not as a distinct conscious step during 
development. I write pieces of code and execute them immediately. It's 
much faster to run the code than to explicitly compile and/or run a type 
checker.

This is a completely different style of developing code.

Pascal

-- 
Pascal Costanza               University of Bonn
mailto:costanza at web.de        Institute of Computer Science III
http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)