On Unit Testing and Type Safety
In the midst of an overall-interesting post on Functional Programming Languages and Silver Bullets, Larry O'Brien makes an interesting observation:
For instance, right now there's a huge debate about explicit typing. Is it helpful or not to declare that a variable is an integer? Meanwhile, there's not a huge debate about the value of unit-testing. That is, everyone agrees that it's helpful to declare that a variable always be greater than 0 and less than, say, 2^32. Is the irony not clear? Unit-testing assertions are type information: constraints on the interpretation of the inherently-plastic memory representation. It seems to me clear that unit-testing specification should migrate into languages, not remain the province of libraries. It ought to be the case that a failure of the unit-testing suite have the same, if not greater, ramification that comes from assigning a signed int to an unsigned one.
While I have a quibble with the way this is expressed (I see the debate as more about how much explicit typing is necessary and when it's best enforced rather than whether or not it's necessary at all; for example, Haskell lets you have an explicit type when it is really needed, and will use type inferencing when it's not), the overall point is quite good, and, if anything, understated. Just as there's a crossover between typing and unit testing, there's also a crossover between unit testing and design by contract, and unit testing and unit testing and automated testing. For us, anyway, unit test failures and compiler warnings do have the same ramification, namely, they kill our automated build. But I like the idea of getting unit testing into the language. This could be an extension of the design by contract ideas from Eiffel.
Please login first in order for you to submit comments