3 ms·

This is where a nice type system and compilation checks in CI are very useful to have.

Gigachad 3y ago
I agree a type system does wipe out 80% of the tests you need, but I still feel like the 20% is useful. You can just write tests that verify the output looks right without having to run every single line of code to make sure there are no typos or type issues.
- reissbaker 3y ago
  Yeah, I think that's one of the driving forces away from high code coverage / dogmatic TDD: dynamically typed languages used to be a lot more popular, and you really do need incredible amounts of testing to keep those working reliably in the long run. Now that typed languages are more popular — while some of the tricky logic parts are still worth testing — you can wipe out a lot of the rest because it simply won't compile when, say, you passed a nullable variable to a function that didn't expect it.
1propionyl 3y ago
Types don't replace tests. Tests don't replace types. For either statement to be true, they would have to be entirely equivalent, at which point it would be a distinction without a difference to complain about. And last I checked no type system automatically generates and minimizes failure cases. And last I checked no test system can be used to formally prove anything about the behavior of code.
- MrJohz 3y ago
  The two are definitely not equivalent, but they overlap. Types can replace tests - if an edge case exists but I can define it out of existence with my type system, then I no longer need tests for that case. And likewise, tests can replace types - I can use dependent type systems to define invariants in my system but at a certain point it becomes so unwieldy that it's easier to use tests to define those invariants less formally. In the end, they're just two different tools that both serve the overall aim of software correctness. Demonstrating correctness with one tool may be easier but less thorough, or more complicated but more precise, or whatever else. In this context, if you can get the type system to help you, you'll be able to get away with a lot fewer tests because you don't need to test things like "does this function call a method that actually exists?" or "what happens when this function is passed bad data?".
- JoeyJoJoJr 3y ago
  Why does the statement need to be either true or false, and why would tests versus a type system have to be entirely equivalent? The parent comment mentioned that 80% of tests can be eliminated with a good type system, not that a good type system can entirely replace tests. IMO working with a good type system for a decent length of should absolutely make it apparent that a whole host basic but pervasive errors are practically eliminated, or at the very least heavily mitigated. Silly errors like thinking an array of numbers is just a number, or an Id is a string instead of an int. Every developer I have ever worked with makes these mistakes all the time, especially the developers that say they have never needed a type system or that type systems somehow limit the expressiveness of their code. I would really like to know if there is an efficient way to write tests that can adequately cover these silly errors without over burdening the codebase with heaps of extra test code that causes rigidity and friction for refactoring.
  - godelski 3y ago
    > Why does the statement need to be either true or false, They never said that btw. They said for a logical system you'd need "types replace tests <=> tests replace types." While I don't agree from a mathematical point, their meaning is clear enough. It's clear that you can have typed systems and still need tests and well... tests obviously don't enforce types. Plus, how does everyone in CS not know that logic systems are not binary but tertiary?

I agree a type system does wipe out 80% of the tests you need, but I still feel like the 20% is useful. You can just write tests that verify the output looks right without having to run every single line of code to make sure there are no typos or type issues.

reissbaker 3y ago
Yeah, I think that's one of the driving forces away from high code coverage / dogmatic TDD: dynamically typed languages used to be a lot more popular, and you really do need incredible amounts of testing to keep those working reliably in the long run. Now that typed languages are more popular — while some of the tricky logic parts are still worth testing — you can wipe out a lot of the rest because it simply won't compile when, say, you passed a nullable variable to a function that didn't expect it.

1propionyl 3y ago

Types don't replace tests. Tests don't replace types. For either statement to be true, they would have to be entirely equivalent, at which point it would be a distinction without a difference to complain about. And last I checked no type system automatically generates and minimizes failure cases. And last I checked no test system can be used to formally prove anything about the behavior of code.

MrJohz 3y ago
The two are definitely not equivalent, but they overlap. Types can replace tests - if an edge case exists but I can define it out of existence with my type system, then I no longer need tests for that case. And likewise, tests can replace types - I can use dependent type systems to define invariants in my system but at a certain point it becomes so unwieldy that it's easier to use tests to define those invariants less formally. In the end, they're just two different tools that both serve the overall aim of software correctness. Demonstrating correctness with one tool may be easier but less thorough, or more complicated but more precise, or whatever else. In this context, if you can get the type system to help you, you'll be able to get away with a lot fewer tests because you don't need to test things like "does this function call a method that actually exists?" or "what happens when this function is passed bad data?".
JoeyJoJoJr 3y ago
Why does the statement need to be either true or false, and why would tests versus a type system have to be entirely equivalent? The parent comment mentioned that 80% of tests can be eliminated with a good type system, not that a good type system can entirely replace tests. IMO working with a good type system for a decent length of should absolutely make it apparent that a whole host basic but pervasive errors are practically eliminated, or at the very least heavily mitigated. Silly errors like thinking an array of numbers is just a number, or an Id is a string instead of an int. Every developer I have ever worked with makes these mistakes all the time, especially the developers that say they have never needed a type system or that type systems somehow limit the expressiveness of their code. I would really like to know if there is an efficient way to write tests that can adequately cover these silly errors without over burdening the codebase with heaps of extra test code that causes rigidity and friction for refactoring.
- godelski 3y ago
  > Why does the statement need to be either true or false, They never said that btw. They said for a logical system you'd need "types replace tests <=> tests replace types." While I don't agree from a mathematical point, their meaning is clear enough. It's clear that you can have typed systems and still need tests and well... tests obviously don't enforce types. Plus, how does everyone in CS not know that logic systems are not binary but tertiary?