Analysis of whether unit testing obviates static type checking (2012)
evanfarrer.blogspot.com
Analysis of whether unit testing obviates static type checking (2012)
1–10 of 65 posts
Re: Analysis of whether unit testing obviates static type checking (2012)
#2Original title: Unit testing isn't enough. You need static typing too.
From 2012.
Re: Analysis of whether unit testing obviates static type checking (2012)
#3TL;DR: The blogger took 4 Python projects, rewrote them in Haskell, and 3 of them had type errors. Therefore unit tests are not replacements for static typing.
---
I don't get how this post says anything about unit testing or static typing at all. Doesn't it just imply that bugs are easier to detect with one method than another method? Most statically typed languages out there have a type system too weak to make the expression 1/0 a compile-time error. But you work around this with linting, unit tests, using a language with a stronger type system, etc.
Re: Analysis of whether unit testing obviates static type checking (2012)
#4TL;DR: The blogger took 4 Python projects, rewrote them in Haskell, and 3 of them had type errors. Therefore unit tests are not replacements for static typing. --- I don't get how this post says anything about unit testing or static typing at all. Doesn't it just imply that bugs are easier to detect with one method than another method? Most statically typed languages out there have a type system too weak to make the…
Yeah, as a big unit testing proponent I'd still definitely say they are not a silver bullet. They simply have a good cost-to-confidence-in-code ratio. So do static types, or type annotated code with strict validation.
Re: Analysis of whether unit testing obviates static type checking (2012)
#5TL;DR: The blogger took 4 Python projects, rewrote them in Haskell, and 3 of them had type errors. Therefore unit tests are not replacements for static typing. --- I don't get how this post says anything about unit testing or static typing at all. Doesn't it just imply that bugs are easier to detect with one method than another method? Most statically typed languages out there have a type system too weak to make the…
But did they have type errors in Python? Or was the type error introduced by translation?
Re: Analysis of whether unit testing obviates static type checking (2012)
#6Original title: Unit testing isn't enough. You need static typing too. From 2012.
In the meantime, mypy has come along, inviting another trip through these projects.
Have any of the python projects acquired type annotations?
Re: Analysis of whether unit testing obviates static type checking (2012)
#7The blog sets up to address the "claim by proponents of dynamically typed programming languages" that "once you have unit testing static type checking is redundant". This is a strawman and I'm fairly sure it was a strawman in 2012 as well. The more interesting claim, which this blog post doesn't address, is that dynamic typing plus unit testing lets you produce working programs faster, without having to wrestle a type system for things you don't care about (e.g. malformed input leading to crashes when parsing machine-generated, standardised inputs, as is the case for three of the test programs -- keeping in mind that, in Python, a crash due to a type error produces an orderly, if surprising, program exit rather than, for example, memory corruption).
Re: Analysis of whether unit testing obviates static type checking (2012)
#8Original title: Unit testing isn't enough. You need static typing too. From 2012.
Not 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.
Re: Analysis of whether unit testing obviates static type checking (2012)
#9The blog sets up to address the "claim by proponents of dynamically typed programming languages" that "once you have unit testing static type checking is redundant". This is a strawman and I'm fairly sure it was a strawman in 2012 as well. The more interesting claim, which this blog post doesn't address, is that dynamic typing plus unit testing lets you produce working programs faster, without having to wrestle a typ…
> The more interesting claim, which this blog post doesn't address, is that dynamic typing plus unit testing lets you produce working programs faster,
That's an interesting question for any program or app in the move-fast-break-things domain. But perhaps a suboptimal, and potentially inaccurate, one for high-assurance systems that can't break without losing substantial financial value or lives, and/or for which system-wide refactoring may be necessary as the system evolves. Know your domain, choose your tools and methodologies appropriately.
Re: Analysis of whether unit testing obviates static type checking (2012)
#10The better the type system is, the more bugs it prevents, so one has to spend less time unit testing. Sadly, it also means the language is harder to learn, so the rest of us are stuck with horrible, unsafe languages.