3 ms·

I don't get the claim that dynamic typing requires more unit tests. Sure if you pass a string to a Python function that expects an int it will blow up at runtim

I don't get the claim that dynamic typing requires more unit tests. Sure if you pass a string to a Python function that expects an int it will blow up at runtime, but is there any value in testing for that?

snprbob86 16y ago
If you are doing TDD and are aiming for near complete specification and coverage, then dynamic languages and static languages will pretty much require the same number of use cases. However, most people don't do TDD. With a dynamic language, your compiler isn't doing entire categories of checks for you. You're putting more responsibility on the tests, so you wind up writing more of them sooner and running them almost as frequently as static language users run their compilers! Since people generally stop long before 100% coverage, you wind up with far more tests for the average dynamic project than the average static one.
- jhpriestley 16y ago
  Complete specification is impossible with tests, except for functions with finite domains. Testing is about reducing bugs to a certain level. Entirely different techniques - namely formal proofs - are required to eliminate bugs. Strong static typing is more effective than tests, in terms of cost/benefit, at reducing bugs.
jhpriestley 16y ago
Static types can encode a lot more information than that. For example, suppose that you are compiling an AST. You start with an AST whose leaves are of type String (identifiers). You want to slot in something else, like pointers to a link table, or values, etc. Maybe some identifiers are builtins which will modify the AST, or user-defined macros, so the transformation will be non-trivial. In a static language, this transformation would be typed as `AST Identifier -> AST Value`, or the like. This guarantees that you haven't missed any identifiers. The guarantees provided by static typing tend to be somewhat orthogonal to the guarantees provided by testing. Testing ensures that, in some particular cases, the function works exactly as it should. Types ensure that, in every case, the function satisfies some properties that it should. The ideal would be every case and every property, but this is only possible with complete proofs. In my experience, types catch more bugs with less effort than tests.

snprbob86 16y ago

If you are doing TDD and are aiming for near complete specification and coverage, then dynamic languages and static languages will pretty much require the same number of use cases. However, most people don't do TDD. With a dynamic language, your compiler isn't doing entire categories of checks for you. You're putting more responsibility on the tests, so you wind up writing more of them sooner and running them almost as frequently as static language users run their compilers! Since people generally stop long before 100% coverage, you wind up with far more tests for the average dynamic project than the average static one.

jhpriestley 16y ago
Complete specification is impossible with tests, except for functions with finite domains. Testing is about reducing bugs to a certain level. Entirely different techniques - namely formal proofs - are required to eliminate bugs. Strong static typing is more effective than tests, in terms of cost/benefit, at reducing bugs.

jhpriestley 16y ago

Static types can encode a lot more information than that. For example, suppose that you are compiling an AST. You start with an AST whose leaves are of type String (identifiers). You want to slot in something else, like pointers to a link table, or values, etc. Maybe some identifiers are builtins which will modify the AST, or user-defined macros, so the transformation will be non-trivial. In a static language, this transformation would be typed as `AST Identifier -> AST Value`, or the like. This guarantees that you haven't missed any identifiers. The guarantees provided by static typing tend to be somewhat orthogonal to the guarantees provided by testing. Testing ensures that, in some particular cases, the function works exactly as it should. Types ensure that, in every case, the function satisfies some properties that it should. The ideal would be every case and every property, but this is only possible with complete proofs. In my experience, types catch more bugs with less effort than tests.