On 7/19/06, Richard Liang <[EMAIL PROTECTED]> wrote:
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?
Hi Richard, For getDisplayName, getDisplayLanguage() and methods like so, which are locale-dependent, I suggest we write implementation tests for them. The test may look like: 1. get default locale 2. get i18n string from ResourceBundle directly 3. get i18n string by locale-dependent method 4. assertEquals Sounds reasonable? Any comments? Thank you! Best regards,
Richard > Regards, > Tim > > -- Richard Liang China Software Development Lab, IBM
-- Andrew Zhang China Software Development Lab, IBM
