Strict typing is the foundation of any non-trivial piece of software. 50-line scripts written by single developers to perform some simple tasks will survive without knowing whether something is a number or a string; large codebases maintained by a group (or even several groups) of people will not. Strict typing comes before developer testing and is a prerequisite. Code with loose typing presents several unnecessary challenges to both developer and manual testing:
- The code needs to be sprinkled with superfluous type checks: “Can the variable i be compared to 42, or is it a string?” Such checks decrease readability and mandate unintuitive test cases.
- Similarly, testing techniques like boundary value analysis and equivalence partitioning become harder to apply, because of partitions of totally irrelevant data. Furthermore, in coarse-grained type systems like, let’s say only string and numbers, the partitions become unnecessarily large, whereas more fine-grained type systems tend to produce smaller partitions out of the box.
- A similar argument can be made from the domain-to-range ratio perspective. Coarse-grained, open type systems will produce both large(er) numbers in both the nominator and denominator of the ratio. A non-mathematical interpretation is: “pretty much any input can produce pretty much any output. Now, test me.”
To sum it up. Loose typing adds degrees of freedom that make both development and testing harder, without adding any benefits in larger systems. Some might argue that loose typing saves time when writing trivial scripts, but that benefit disappears immediately at the first hint of non-trivial behavior.