I’ve started to look into the whole unit testing/test-driven development idea, and the more I think about it, the more it seems to fill a similar role to static type checking. Both techniques provide a compile-time, rapid-response check for certain kinds of errors in your program. However, correct me if I’m wrong, but it seems that a unit test suite with full coverage would test everything static type checking would test, and then some. Or phrased another way, static type checks only go part of the way to ‘prove’ that your program is correct, whereas unit tests will let you ‘prove’ as much as you want (to a certain extent).
So, is there any reason to use a language with static type checking if you’re using unit testing as well? A somewhat similar question was asked here, but I’d like to get into more detail. What specific advantages, if any, does static type checking have over unit tests? A few issues like compiler optimizations and intellisense come to mind, but are there other solutions for those problems? Are there other advantages/disadvantages I haven’t thought of?
I would think that automated unit testing will be important to dynamic typed languages, but that doesn’t mean it would replace static type checking in the context that you apply. In fact, some of those who use dynamic typing might actually be using it because they do not want the hassles of constant type safety checks.
The advantages dynamically typed languages offer over static typed languages go far beyond testing, and type safety is merely one aspect. Programming styles and design differences over dynamic and static typed languages also vary greatly.
Besides, unit tests that are written too vigorously enforce type safety would mean that the software shouldn’t be dynamically typed after all, or the design being applied should be written in a statically typed language, not a dynamic one.