It’s worse than that though — he believes an exception will be thrown, but doesn’t have a test showing it.
Indeed in many dynamically typed languages an argument of the ‘wrong’ type is silently coerced in possibly unexpected ways.
Indeed in many dynamically typed languages an argument of the ‘wrong’ type is silently coerced in possibly unexpected ways.
he is applying risk based assessment which tests are required to provide a high quality implementation.
If a system misbehaves you will catch in higher level tests in the test pyramid eventually.
The bug was found regarding the null pointer, he can and should add a dedicated unittest to reproduce the issue when he fixes the bug, since there is evidence that his assessment was wrong. This is not bad but usually quite efficient if this doesn't occur often or has a large impact on the system's user base.
In a software solution you can't prove 100% correctness - neither through "standard" type-systems nor through tests.
If you want to show formal correctness of a program have a look at https://cs.stackexchange.com/questions/13785/formal-program-...
You might catch it eventually, or you might not. That's the problem with hoping you write enough tests.
> he can and should add a dedicated unittest to reproduce the issue when he fixes the bug
His argument is that dynamic language don't 'really' require writing more exhaustive tests than in an expressive static language. In this scenario, not only would he need to write an extra test but he also needs to spend time after the fact tracking down an error thrown in a higher-level function.
> In a software solution you can't prove 100% correctness
This isn't about proving 100% correctness, it's about what happens when you pass a non-list into a list processing function. More expressive type systems allow you to reduce the number of nonsensical questions you have to answer.