harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: [testing] locale dependent tests
Date Mon, 24 Jul 2006 14:30:56 GMT

>-----Original Message-----
>From: Paulex Yang [mailto:paulex.yang@gmail.com]
>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 <richard.liangyx@gmail.com> wrote:
>>> Tim Ellison wrote:
>>> > Richard Liang wrote:
>>> >
>>> >> Although the spec does not require the round-trip of applyPattern
>>> >> 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
>>> > the test assertions valid, you could work with the default locale
>>> > 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
>>> > en_US go ahead and assert more round-tripping code, otherwise
>>> test
>>> > it as the spec allows variances.
>>> >
>>> >
>>> If a test case passes in all locales, could we think that the
>>> tested by the test case is locale-independent? We still have to
>>> 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
>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
>find some. i.e., I don't think we need ABC_en_US_Test, or so.

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

Any thoughts?


>> Hi Richard,
>> For getDisplayName, getDisplayLanguage() and methods like so, which
>> 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
>Terms of use : http://incubator.apache.org/harmony/mailing.html
>To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Alexey A. Ivanov
Intel Middleware Product Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message