3 ms·
Original title: Unit testing isn't enough. You need static typing too. From 2012.
by kristianp 3y ago
Original title: Unit testing isn't enough. You need static typing too.
From 2012.
- smitty1e 3y agoIn the meantime, mypy has come along, inviting another trip through these projects. Have any of the python projects acquired type annotations?
- pfdietz 3y agoNot that unit testing is enough, but the unit testing that these projects happened to do isn't enough. I suggest that testing that's enough to have confidence that a non-trivial program is correct is going to cover just about everything static type checking could find as well (except in dead code, and how does that matter?) Or, to put it another way, if you didn't care enough about the correctness of your code to test it adequately, why would you care that static type checking could find some bugs? You've already determined quality is not too important.
- xupybd 3y agoEnough unit testing will test everything the type system can. However, that is way more work than a good type system.
- chriswarbo 3y ago> Enough unit testing will test everything the type system can Depends on the type system. For example, if we have parametricity then we can constrain possible values quite a lot; e.g. a value with type 'forall t. t -> t' is the identity function (or diverges, if our language is non-total). If we don't have parametricity, such values could do all sorts of shenanigans, e.g. def f[T](x: T): T = x match { case n: BigInt if isOdd(n) && isPerfect(n) => n+1 case _ => x } This acts as the identity function for all values of all types; except if we give it a BigInt which is an odd perfect number. This is probably the identity function, but ensuring there are no edge cases would require our test suite to solve a famously hard problem https://en.wikipedia.org/wiki/Perfect_number#Odd_perfect_numbers https://en.wikipedia.org/wiki/Perfect_number#Odd_perfect_num... (This sort of guarantee is known as a "free theorem", e.g. see https://bartoszmilewski.com/2014/09/22/parametricity-money-for-nothing-and-theorems-for-free https://bartoszmilewski.com/2014/09/22/parametricity-money-f... )
- golergka 3y ago> if you didn't care enough about the correctness of your code to test it adequately, why would you care that static type checking could find some bugs? I think you got this backwards. If you didn't care enough about the correctness of your code to even do something as simple and straightforward as using a proper type system, why would you spend enormous amount of time to write and then support unit tests just so that they could find some bugs?
- pfdietz 3y agoI do care about the things type checking could find. I just don't care to use type checking to find them, because I'd find them by doing other activities (extensive testing) that I'd do anyway.
- golergka 3y agoThe main difference is, nobody checks if you wrote tests for every failure condition. Choose coverage tries, but it doesn't really come close enough to type checker.
- pfdietz 3y agoSo, you're saying nobody actually cares if the code is correct. So why should I?
- golergka 3y agoNo, I'm saying that I would rather depend on an automated tool than human decision. That's why you use automated testing instead of manual, right? Static typing is just the next step in the same direction.
- pfdietz 3y agoBut the automated tool (static type checker) does not actually produce reliable software. Only extensive testing does that. And if you do extensive testing, why do you need that automated tool? The static type checker is only useful (in the sense of making the software more reliable) if the testing is inadequate. In which case, the software is going to be crap anyway. You might argue that enforcing static type checking cause the software to be structured in some way that's helpful, but that's a different argument.
- throwawaymaths 3y agoIt goes the other way, too. There are definitely people out there that don't write tests because they think types save you from that.