Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
I want the function to fail when it is passed the wrong arguments, but I don't really care about how exactly it fails. If the wrong types get passed to a function, I'm already screwed and there's no way to do the right thing at that point. I only care that I get enough information to debug what happened.
In pretty much any other case, I want to function return some precise value or do some precise action. These are situations that the code will encounter during normal execution, and so I do care about what exactly it does.
Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production.
Writing specific tests for that looks very inefficient to me but maybe I am missing something.
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.
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.
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.
* true as in all possible inputs and outputs rather than merely all code paths
Your comment just solved the problem by ignoring the latter, not much of a contribution to say the least.
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.