Should we test edge cases and invalid input in our tests?
As an example we have: https://github.com/exercism/problem-specifications/blob/master/exercises/armstrong-numbers/canonical-data.json
Should we add the following tests to that track and others that are similar (consider it a more general qustion, but this example is specific)?
I see we have some specifications that cover negative numbers for example, but not all of them.
As far as I am concerned the tests are good as they are, and I don't want to over complicate things or go into too much details.
The reason why I think this might help, is that it will help user handle parsing input.
For example in bash, if you don't force the user to handle the input he might not bump into the fun world of passing input from CLI to functions, and handling whitespace, comparing string with integers or handling arguments with spaces.
We settled once to not test for inputs that are not possible to create in any reasonable type checking compiler.
You simply can't pass a string as a number or too many or to less arguments in such systems.
If though a language that allows to pass in strings for numbers such edgecases should be added to the canonical tests by that tracks maintainers.
refer to #902.
Thank you.
Most helpful comment
We settled once to not test for inputs that are not possible to create in any reasonable type checking compiler.
You simply can't pass a string as a number or too many or to less arguments in such systems.
If though a language that allows to pass in strings for numbers such edgecases should be added to the canonical tests by that tracks maintainers.