4 ms·

I disagree with the bit about test-driven development. It is not necessary to add tests specifically for type errors. Unit tests for basic functionality will

by finnw 15y ago

I disagree with the bit about test-driven development. It is not necessary to add tests specifically for type errors. Unit tests for basic functionality will usually catch them.

bunderbunder 15y ago
They won't do so reliably if you're working in a larger or longer-lived project. Then there's much more chance for a mental disconnect between the writing of a procedure and the usage of the procedure. (Either in the form of each being done by a different person, or the same person but with some 'forgetting time' in between.) There's also much more chance for the source to start to acquire a large collection but almost-but-not-quite-the-same types. The unit tests that were written with the original procedure are likely to only cover usage scenarios that are expected by the person who just wrote the procedure. Someone who's not in that headspace can easily be a lot more "creative" about coming up with surprising ways to try and use the code. So easily that it might even happen by accident. Like, say, as a result of a simple refactor. So in a reasonably-sized project, unit tests for basic functionality end up being a rather short Maginot Line for type errors.
Peaker 15y ago
His first buggy example would not be caught by a typical unit test...
- finnw 15y ago
  The integer overflow bug? It depends on the quality of the test. It makes sense to test with the same types you intend to use in production, and to cover a wide range of values within each type (the array [1,2,3] for example would not be a good test for 64-bit integers.) And static typing would not necessarily catch this bug anyway. A C++ template or a polymorphic Haskell function would fail in exactly the same way. What is called for here is argument conversion (A C function or java method declared with double arguments would convert its arguments automatically, but no reason you cannot convert explicitly in a dynamic language.)

by finnw 15y ago

I disagree with the bit about test-driven development. It is not necessary to add tests specifically for type errors. Unit tests for basic functionality will usually catch them.

bunderbunder 15y ago

They won't do so reliably if you're working in a larger or longer-lived project. Then there's much more chance for a mental disconnect between the writing of a procedure and the usage of the procedure. (Either in the form of each being done by a different person, or the same person but with some 'forgetting time' in between.) There's also much more chance for the source to start to acquire a large collection but almost-but-not-quite-the-same types. The unit tests that were written with the original procedure are likely to only cover usage scenarios that are expected by the person who just wrote the procedure. Someone who's not in that headspace can easily be a lot more "creative" about coming up with surprising ways to try and use the code. So easily that it might even happen by accident. Like, say, as a result of a simple refactor. So in a reasonably-sized project, unit tests for basic functionality end up being a rather short Maginot Line for type errors.

Peaker 15y ago

His first buggy example would not be caught by a typical unit test...

finnw 15y ago
The integer overflow bug? It depends on the quality of the test. It makes sense to test with the same types you intend to use in production, and to cover a wide range of values within each type (the array [1,2,3] for example would not be a good test for 64-bit integers.) And static typing would not necessarily catch this bug anyway. A C++ template or a polymorphic Haskell function would fail in exactly the same way. What is called for here is argument conversion (A C function or java method declared with double arguments would convert its arguments automatically, but no reason you cannot convert explicitly in a dynamic language.)