does it make sense to verify the types and write unit tests that unexpected types are dealt with properly
Sort of - replace "unit tests" by "automatic tests", and then the answer becomes yes.
If you have a function A expecting an object B as input, and a component C calls A, in a statically typed language the compiler will complain if C tries to pass something which is not B (or a derivation of B).
In a dynamically typed language, you won't get a compiler error if the passed object is not a valid replacement for B. Such errors can stay undetected until the code is executed. In such a situation, an automated test for C (using A) can indeed work as an alternative for the missing compiler checks. (If that test is more a unit test for C, or an integration test for C&A may depend on what A and C are in your system, but it does not really matter how you call it).
If you should do this, how much effort you should invest into these additional tests, is a different question. This cannot be answered in general and depends heavily
- on the size and complexity of the system,
- the test process for the system in general
- non-functional requirements like maintainability, evolvability or reliability
- financial impact of errors which slip into production
and so on. Maybe there are other, coarser integration tests which cover the execution of the components in stake. Maybe there is a manual testing process which is sufficient to catch most of the bugs. Maybe you can afford when the parts fail in production, since when this happens, the dev team gets noted and can fix this early enough. In the end, this is always a trade-off.
Note that you have to deal with the question of tests and errors in production even when using a statically typed language - type safety and/or additional tests can only reduce the probability of production failures to a smaller value, but never to zero.