From: Marcin 'Qrczak' Kowalczyk Date: 2002-09-30T07:57:22+09:00 Subject: Re: thoughts on typelessness Mon, 30 Sep 2002 00:49:08 +0900, Dossy pisze: > Sounds like static typing is an excuse not to always aim for as > close to 100% test coverage as possible. Covering 100% of code with tests is not a silver bullet. What if code producing some data is covered by tests and code consuming that data is covered by tests, but sometimes the producer emits data which is not understood by the consumer? Each taken in isolation looks correct because the form of the data is not formally specified. Even if tests do cover the relevant code, it takes time to understand why a test fails, or maybe that this is the test which is out of date. Imagine a compiler with a tree representing the internal form of the code. In a statically typed language the type of the tree (possible forms of nodes with arguments) is specified in one place. When I change the representation of a construct, I change this specification first and try to compile the compiler. I will be immediately told where these nodes were produced from the previous stage and where they were consumed by later stages. How to specify valid shape of the tree with tests and ensure that - the producer produces only valid code no matter what the input is, - the consumer understands all valid code? Static typing just makes it much easier and more straightforward. > Is this a wise approach? Is there ever a time that the program > doesn't benefit from having test coverage closer to 100%? You don't need tests which check that the producer emits nodes only from the given set if types ensure that. You don't need tests which ensure that only lists of expressions are put in the "function call" node in place of arguments - the compiler checks this, etc. Many tests are reduntant when types are checked statically - they are even impossible to write because otherwise the program would not compile. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/