sahvx655-wq commented on code in PR #430:
URL: https://github.com/apache/commons-validator/pull/430#discussion_r3673581638
##########
src/test/java/org/apache/commons/validator/routines/CurrencyValidatorTest.java:
##########
@@ -176,6 +179,21 @@ void testPattern() {
assertFalse(validator.isValid(ukPound + "1,234.567", pattern,
Locale.US), "invalid symbol");
}
+ /**
+ * Test currency values with a pattern that suffixes the symbol, which
locales such as de-DE separate from the number with a non-breaking space. The
symbol
Review Comment:
Fair point, the javadoc claimed de-DE while the assertions only ever ran
against en-US symbols. There's now a parameterised testSuffixSymbolLocale
covering de-DE, fr-FR and sv-SE against the JVM's own currency format, with the
pattern, separator and inputs all derived from the locale data at run time;
that matters because the separator has drifted between CLDR releases (fr moved
from U+00A0 towards U+202F), so hardcoding any one character would either rot
or fail on older JVMs. On a JVM whose data doesn't space-separate a suffix
symbol the case skips via an assumption instead of asserting stale data, and
the explicit-pattern US test stays as the pinned variant.
On covering all known currency symbols: at pattern level there is only the
one placeholder, U+00A4, and the concrete sign is substituted per locale from
DecimalFormatSymbols, so varying the locale is what varies the symbol. The new
set exercises the euro and the Swedish krona alongside the dollar and pound
already in this file. Each locale case fails on master with 'no symbol ==>
expected: <1234.56> but was: <null>' and passes with the fix.
##########
src/test/java/org/apache/commons/validator/routines/PercentValidatorTest.java:
##########
@@ -100,6 +105,21 @@ void testNumberRangeExactBound() {
assertFalse(instance.minValue(new BigDecimal("5"), new
BigDecimal("5.5")));
}
+ /**
+ * Test percentage values with a pattern that suffixes the symbol, which
locales such as fr-FR separate from the number with a non-breaking space. The
Review Comment:
Same treatment as the currency test: a parameterised testSuffixSymbolLocale
now runs fr-FR and de-DE against NumberFormat.getPercentInstance with the
pattern and separator read from the locale data at run time, and the
explicit-pattern test keeps the pinned en-US expectations. The assumption guard
means a JVM whose percent data has no space-separated suffix (the older
legacy-data JREs) skips the case rather than failing on data the fix can't
influence.
Both locale cases fail on master, 'no symbol: fr_FR ==> expected: <0.12> but
was: <null>', and pass with the change, so the claim in the comment is now
backed by an assertion rather than prose.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
