> The testing burden in dynamically typed languages is not > greater than the testing burden of statically typed > languages, provided that you do functional testing for all > your requirements. Actually, the testing burden is equal > in both cases.
I've thought about it, and I've decided that static type checks are not tests. Tests are dependent on codepath. Each test excerises a different codepath (well, more-or-less, some may validate that several different inputs have the same codepath). While static type checking is completely independent of codepath.
More generally, tests are purely empirical, while static type checks are purely deductive.
The point of my comments is that static type checking immediately detects a class of errors that I commonly see in my own code that are very difficult, or even impossible, to detect via testing except by chance.
Unit tests are not enough, because often times the place where the error is introduced (e.g., a member variable is set to a tuple instead of an integer) is often distant, both within the code and within execution of the program, from where the error causes failure (when arithmetic operations are attempted on the tuple). Only integrated testing can detect these errors, and even then a huge set of tests is required. Unless, of course, you specify the types of the member variables on the object and validate them at runtime or check all of them in your tests. In which case you've lost both the time savings and flexibility gain of dynamic typing.
Previous Topic
