If you use your type system to make invalid states impossible to represent & your functions are pure, there less—maybe nothing—to test, which will save you from this scenario.
Nothing toy-like about using ADTs to eliminate certain cases. When all cases are handled, your tests can move from a micro state to a macro state. Contraint types or linear types can be used to only allow certain sizes of inputs or require all file handles be closed when opened.
Naturally if your language’s type system is bad you can’t make these compile-time guarantees tho. Heck, a lot of developers are still using piss-poor languages with null or the infernce sucks with any.
If you use your type system to make invalid states impossible to represent & your functions are pure, there less—maybe nothing—to test, which will save you from this scenario.
You can’t have any bugs if you don’t write any code.
Nothing to test? Lol what.
def add(a: int, b: int) -> int: return a * b
All types are correct. No side effects. Does the wrong thing.
Maybe it’s doing the right thing but is badly named
Maybe the it’s the English language that is wrong?
Old and busted: Fix the function
New hotness: Redefine enough words in the English language such that the function is now correctly implemented
It must be nice to work only with toy cases where this is feasible.
Nothing toy-like about using ADTs to eliminate certain cases. When all cases are handled, your tests can move from a micro state to a macro state. Contraint types or linear types can be used to only allow certain sizes of inputs or require all file handles be closed when opened.
Naturally if your language’s type system is bad you can’t make these compile-time guarantees tho. Heck, a lot of developers are still using piss-poor languages with
nullor the infernce sucks withany.