Tim Ellison wrote:
Richard Liang wrote:
Although the spec does not require the round-trip of applyPattern and
toPattern, we still want to get one *certain* pattern through toPattern.
Now the problem is the returned pattern is locale-dependent. I'm
uncertain about the reason to remove the assertion:
1) Because the behavior is not required by spec, or
2) Because the behavior is locale-dependent
It would seem that rather than forcing the locale to be en_US to make
the test assertions valid, you could work with the default locale and
guard any assertions that are locale-specific. It would seem a shame to
loose the diversity of testing on multiple locale machines if the tests
always force everyone to look like an American (horror! ;-) )
I would expect the fix therefore to be something like, if locale is
en_US go ahead and assert more round-tripping code, otherwise can't test
it as the spec allows variances.
If a test case passes in all locales, could we think that the behavior
tested by the test case is locale-independent? We still have to think
about how to test locale-dependent behavior. For example,
java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To
verify both the code logic and locale data, shall we have some tests
like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test?
Best regards,
Richard
Regards,
Tim
--
Richard Liang
China Software Development Lab, IBM
