> It tests at compile time that some function f takes A and returns B. That covers 99% of all possible input/output which you technically have to do in an untyped language.
Sorry, I don't understand what you are saying here. By A and B are you referring to the correct output given an input, or just to the expected data type? Because there is a big difference, as with the `min()` example.
yes because the set of possible inputs for A -> C is basically infinite. But min(A,B)=C is only 2^64^2. Why shouldn't you test for string, object, object of object, object with a certain kind of shape, or Number class as opposed to number primitive? How can you know it will or won't work from a unit test perspective?
But the purpose of unit tests is to show that the code under test is correct, i.e. that min() return the smallest input, not just a random value of the same type. Static typing cannot do that, so it is in no way a substitute for unit tests.
Static typing is a useful tool, just not a substitute for any unit tests. The risk of static typing is when it becomes a goal in itself and you start thinking correctness means the program satisfies the type checker.
Sorry, I don't understand what you are saying here. By A and B are you referring to the correct output given an input, or just to the expected data type? Because there is a big difference, as with the `min()` example.