For sure, and if you're someone who loves runtime assertions for type mis-matches, then I think you'd really love static type assertions, which are basically the same thing, but checked earlier, making bugs they find cheaper.

I agree that writing specific tests for that is very inefficient, and that few people (myself included) actually do it. I just also think the fact that people don't really write tests for a (anecdotally) common cause of bugs, and instead wait to see them in their production logs, is an anti-pattern, rather than a positive thing.

So, wait, what exactly is the common source of bugs? How does writing tests passing the incorrect types to function help catch them?

I don't see how this reduces the need for a test that the wrong type is handled correctly.

The underlying idea is that it shouldn't handle the wrong type at all, it should fail.

If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.

And you don't need tests to make sure the assertions are there?

Interesting point :)

At some point you have to assume something is there and correct (e.g., you don't write tests to check whether the tests are there, also you assume the testing tools work, ...).

In static languages you also assume the programmer set the right type for the function argument, so you might as well assume to have an assertion in the critical code of the functional languages.

> At some point you have to assume something is there and correct

If you excel at compositional design then this may work OK but a lot of code bases I have worked on just need a good ol' refactor to sort the mess out. And then the "there and correct" part could fail due to human error, or the new person not knowing the old assumptions etc. The asserts are a step in the right direction in documenting the assumptions though. Types go one level better by both documenting the interface, and enforcing that contract at compile time.

Do you need a test to verify that your compiler correctly checks the type signature? (Actually, that could be occasionally useful in the face of implicit conversions)

You can't get true 100% coverage* on digital hardware. (on quantum maybe!) so what to test or not is always a judgement call. Most of the time I'd assume the software stack is trustworthy but if you are doing something extreme you may want to test the compiler or even formally prove the compiler works as expected.

* true as in all possible inputs and outputs rather than merely all code paths

Perhaps a better way to ask my question: do you write a test to make sure your type signature was correct?

My compilers have test suites.

And the compiler that generates the assert also has a test suite for that.

Yes, you are missing a statically typed language. Tests or assertions? Neither. Security or efficiency? Both.

The grand-grandparent of your comment talked specifically about tests in static vs. dynamic languages.

Your comment just solved the problem by ignoring the latter, not much of a contribution to say the least.