>-----Original Message----- >From: Paulex Yang [mailto:[EMAIL PROTECTED] >Sent: Thursday, July 20, 2006 10:27 AM >To: harmony-dev@incubator.apache.org >Subject: Re: [testing] locale dependent tests > >Andrew Zhang wrote: >> 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? > > >I still confuse what we want to test, the logic or the data? I think >most (if not all) i18n related methods actually have same single >executable with multiple resource bundles, i.e., the single executable >should be locale-independent, the different return value is due to the >resource data difference. I think at least for now, we should pay our >attention to logic of single executable, and leave the data verification >to the i18n libraries' author, say, ICU, they have much more knowledge >and authority (at least than me) on this area. > >If we can get agree on the above, so the i18n related test cases >organization are easier to judge: the logic is locale-independent, so >ideally the tests should be locale-independent, but we have some >exceptional cases, say, the en_UK in MessageFormat case, so we cannot >make our tests rely on the default locale, then we just specify one >locale(en_US) to the tests, and supplement some exceptional case when we >find some. i.e., I don't think we need ABC_en_US_Test, or so. > >Comments? >
I don't think we need several test cases like ABC_en_US_Test and ABC_ru_RU_Test because users can modify locale data. Perhaps not all data can be changed, but some can be surely, for example, date/time formats, decimal and group separators. Thus a test which passes on one machine can fail on another one because locale data are different from the default values. So, I think the best way to deal with such tests is to provide a "fake" hard-coded locale which can't be changed at all. And tests will become locale-independent. Any thoughts? Thanks, Alexey. > >> >> >> 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 >If we write test cases like this, these tests are probably >locale-independent, because: the executable is probably single. I don't >think we should have many "locale-dependent" methods, we just have many >methods with "locale-dependent" data. >> >> Sounds reasonable? >> >> Any comments? Thank you! >> >> Best regards, >>> Richard >>> >>> > Regards, >>> > Tim >>> > >>> > >>> >>> -- >>> Richard Liang >>> China Software Development Lab, IBM >>> >>> >>> >> >> > > >-- >Paulex Yang >China Software Development Lab >IBM > > > >--------------------------------------------------------------------- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
