Should I test the aspects that type checking covers?

Question

For example, should I test like this:

// it shouldn't even compile since I'm using a static type-checking
expect(addTen('string')).toThrowError()

when it is already type-checked like this:

function addTen(n: number): number {
    return n + 10;
}

Answer 1

No, you should not write such tests.

First of all, these tests can't execute. To make this test runnable, you would have to create a small program containing the error and then run the compiler, checking its output for errors. That's perfectly doable, but it isn't fast. The only scenario where I have seen such tests is the ./configure script in Autotools-based C or C++ projects, which compiles small programs to test for the existence and availability of various features and libraries of the host system. But those are not unit tests.

More importantly, you shouldn't write such tests because the test provides less value than the static type system. Static type systems are automated proof systems. If you declare a parameter as int then you are guaranteed that the parameter will never receive a value of any other type. Your test just demonstrates that the function would reject a particular value, not that it will always reject all illegal values. Test are examples of correctness, not proof of correctness. A formal proof is a much stronger guarantee than a test.

You would of course write such tests if the system under test is a type checker. Then the type system, not the function, should reject this program.

The other scenario where such tests are desirable is in dynamically typed language. Since no type system ensures that only suitable parameters are provided, defensive coding becomes more important. The system boundaries (i.e. the public API of your program) should validate all incoming data to verify that it conforms to the documented contract. Since this generates errors immediately at the system boundary, errors stemming from accidentally wrong use of these functions becomes much easier to debug. And just like any other feature, this validation ought to be tested.

Answer 2

A test which doesn't compile can't be a test of your code - it won't run and there is no way to make it run, much less pass. You could use such a test if you were writing a compiler for a statically typed language to verify the type checking.