I had a mentoring session on ISBN Verifier. The student replaced X$ with the string 10 so that the isbn length became 11. The student does not check for length greater than 10.
Instead of adding 1 * isbn[9] to the sum, the remaining digits isbn.substring(9) (from index 9 to the end) parsed to an int are added.
None of the existing test cases failed.
Can we add a new case:
{
"uuid": "...",
"description": "only one check digit is allowed",
"property": "isValid",
"input": {
"isbn": "3-598-21508-96"
},
"expected": false
}
In this case, the weighted sum of the “359821508” digits plus the “check number” 96 is divisible by 11, but there are too many check digits.
For this solution, your algorithm allows invalid input. Because you’re not checking that the input length is greater than 10, then '3-598-21508-96' improperly passes: the weighted sum of the “359821508” digits plus 96 is divisible by 11. But this is not a valid ISBN.
Your code does not obey this constraint from the instructions:
The ISBN-10 format is 9 digits (0 to 9) plus one check character (either a digit or an X only).
I’m conflicted on this ;) This case seems reasonable, but I’m wary of the “trending towards entropy” and adding a test case for every which buggy implementation that shows up.
These are not input-unknown cases, but they catch real incorrect implementations. I think it’s good that we add those test cases and we should remain extremely vigilant to not add complexity or defensive programming practices (like you say: doesn’t need to be exhaustive).
With the trend of less people asking for mentorship, I think this is the best way to help our students!
I share @SleeplessByte position on catching more wrong implementations but not adding new constraints / functional rules. So +1 for me to add the test.
