isbn-verifier: Test only the fact that each case claims to test#993
Merged
petertseng merged 1 commit intoexercism:masterfrom Nov 2, 2017
petertseng:isbn
Merged
isbn-verifier: Test only the fact that each case claims to test#993petertseng merged 1 commit intoexercism:masterfrom petertseng:isbn
petertseng merged 1 commit intoexercism:masterfrom
petertseng:isbn
Conversation
isbn-verifier 1.1.0 "X is only valid as a check-digit" #924 (comment) An implementation that unconditionally treats X as 10 will still reject the ISBM 3-598-2X507-0 3 * 10 + 5 * 9 + 9 * 8 + 8 * 7 + 2 * 6 + 10 * 5 + 5 * 4 + 0 * 3 + 7 * 2 + 0 * 1 = 299, and 299 is not divisible by 11. If the intention of this test is to ensure that an implementation only treats X as 10 in the check digit position, then a case such as 3-598-2X507-9 is needed. The following may be run in a terminal to ensure that this ISBN does sum to a multiple of 11 under such a mistaken implementation: ruby -e 'p "3-598-2X507-9".delete(?-).chars.reverse.map.with_index { |c, i| (c == ?X ? 10 : Integer(c)) * (i + 1) }.sum % 11' "too long isbn" #924 (comment) An implementation that would potentially attempt to checksum ISBNs that are too long would still reject this input because it would see that the "A" is invalid. If the intention of this case is to ensure that an implementation does in fact reject ISBNs that are too long, at the very least a valid character should be used instead of A. If one wanted to be thorough, one might have to include three different cases here, respectively checking for implementations that try to checksum: * all 11 resulting digits (with a coefficient of 11 on the leftmost one, naturally) * the 10 rightmost digits * the 10 leftmost digits by providing a too-long ISBN that has a valid check digit under each respective scheme. This is not done in this PR because it has not yet become apparent through submissions that such three cases are necessary (submissions that unconditionally attempt to checksum using any of the three schemes listed).
Insti
approved these changes
Nov 1, 2017
N-Parsons
approved these changes
Nov 1, 2017
Member
Author
|
Implementing tracks: ECMAScript, Elixir, Go, JavaScript, soon to be Rust and Haskell as well. |
4 tasks
nathanielknight
added a commit
to nathanielknight/problem-specifications
that referenced
this pull request
Jun 25, 2018
This commit adds an input that will be incorrectly validated by algorithms that don't explicitly check the length of their inputs, as discussed in exercism#1199 and exercism#993. For example, if an algorithm only checks the first (or last) ten digits of the input, ignoring leftovers, it will pass the current test suite even though it doesn't correctly implement the spec. closes exercism#1199
rpottsoh
pushed a commit
that referenced
this pull request
Jul 1, 2018
* isbn-verifier: Crafted input to catch more incorrect algorithms This commit adds an input that will be incorrectly validated by algorithms that don't explicitly check the length of their inputs, as discussed in #1199 and #993. For example, if an algorithm only checks the first (or last) ten digits of the input, ignoring leftovers, it will pass the current test suite even though it doesn't correctly implement the spec. closes #1199 * Remove old length test case The "too long no dashes" test case will serve the same purpose, and will allow certain solutions that don't check length (e.g. that test the first or last ten digits of the input, or that generalise the checksum to more digits) to look like they're working until they reach the new "too long but contains valid isb" exercise.
petertseng
added a commit
to exercism/haskell
that referenced
this pull request
Aug 1, 2018
Handles all three possible implementations: * Truncate left * Truncate right * Consider all 11 exercism/problem-specifications#993 (comment) exercism/problem-specifications#1199 exercism/problem-specifications#1255
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
isbn-verifier 1.1.0
"X is only valid as a check-digit"
#924 (comment)
An implementation that unconditionally treats X as 10 will still reject
the ISBN 3-598-2X507-0
3 * 10 + 5 * 9 + 9 * 8 + 8 * 7 + 2 * 6 + 10 * 5 + 5 * 4 + 0 * 3 + 7 * 2 + 0 * 1 = 299,
and 299 is not divisible by 11.
If the intention of this test is to ensure that an implementation only
treats X as 10 in the check digit position, then a case such as
3-598-2X507-9 is needed.
The following may be run in a terminal to ensure that this ISBN does sum
to 10 under such a mistaken implementation:
"too long isbn"
#924 (comment)
An implementation that would potentially attempt to checksum ISBNs that
are too long would still reject this input because it would see that the
"A" is invalid.
If the intention of this case is to ensure that an implementation does
in fact reject ISBNs that are too long, at the very least a valid
character should be used instead of A.
If one wanted to be thorough, one might have to include three different
cases here, respectively checking for implementations that try to
checksum:
by providing a too-long ISBN that has a valid check digit under each respective scheme.
This is not done in this PR because it has not yet become apparent
through submissions that such three cases are necessary (submissions
that unconditionally attempt to checksum using any of the three schemes
listed).