3 ms·
> testing for inputs which would otherwise be clearly impossible in the context of the whole system Off the top of my head... 1. When reusing code, unit tests
by Supermancho 7y ago
> testing for inputs which would otherwise be clearly impossible in the context of the whole system
Off the top of my head...
1. When reusing code, unit tests that specify unexpected inputs are useful because you don't know the future use case. That's a rather weak reason to write the unit tests now, but a reason.
2. There is no way to enforce what is an expected input to a function, once a system grows large enough. Changes in the upstream dataflow being traced through the system by investigating every unit test is impractical. Being defensive up front, is reasonable.
- cageface 7y agoThere is no way to enforce what is an expected input to a function, once a system grows large enough. This is exactly what typechecking does for you and is the reason I think trying to build any large system without them is a bad idea.
- Supermancho 7y ago> This is exactly what typechecking does for you Having types, isn't a binary choice. eg Generics, plain objects, functions, pointers. There are inevitably gaps in how the type system can ensure your what your outputs will be (even if it's a halt).
- cageface 7y agoSure, in an absolute sense. But in practical terms they are fantastically helpful here.
- userbinator 7y agobecause you don't know the future use case ...and thus you shouldn't care about it. I've seen enough problems caused by attempts at "futureproofing" to know that YAGNI is always a good choice. When/if it does matter, then you can do the work; but inevitably, requirements always seem to change in such a way that your attempts to anticipate them results in code that's structured to be flexible in exactly the wrong way, adding unnecessary complexity, or even hinders the desired changes.