[
https://issues.apache.org/jira/browse/VALIDATOR-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14216483#comment-14216483
]
Sebb commented on VALIDATOR-336:
--------------------------------
I agree that there are is a problem with the design of the
AbstractCheckDigitTest class.
The problem is that the same strings are passed both to isValid(String), which
expects the check digit to be present at the end, and also to
calculate(String), which generates the missing check digit. See VALIDATOR-344.
> CUSIPCheckDigit Thinks Invalid CUSIP is Valid
> ---------------------------------------------
>
> Key: VALIDATOR-336
> URL: https://issues.apache.org/jira/browse/VALIDATOR-336
> Project: Commons Validator
> Issue Type: Bug
> Reporter: Josh Meyer
> Attachments: CUSIPCheckDigit.java.patch, CusipValidatorTest.java,
> CusipValidatorTest_v2.java, VALIDATOR-336.patch
>
>
> When testing if a specific CUSIP is valid using
> org.apache.commons.validator.routines.checkdigit.CUSIPCheckDigit.CUSIP_CHECK_DIGIT.isValid,
> a call to this returns true when it should return false. A specific example
> is with the following invalid CUSIP: DUS0421CW.
> What seems to be happening is when toInt is called on W it turns it to an int
> value and then sends it to weightedValue. This is fine for the first 8
> characters of a CUSIP, but not the check digit. The expected result should be
> to return false because the check digit is a letter (on a CUSIP a check digit
> must be 0-9).
> With the current implementation, I believe each CUSIP can have up to 4 valid
> check digits.
> A test is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
