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 Tue, 25 Jul 2006 12:06:06 GMT

>-----Original Message-----
>From: Richard Liang [mailto:richard.liangyx@gmail.com]
>Sent: Tuesday, July 25, 2006 3:41 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [testing] locale dependent tests
>
>
>
>Ivanov, Alexey A wrote:
>>> -----Original Message-----
>>> From: Richard Liang [mailto:richard.liangyx@gmail.com]
>>> Sent: Tuesday, July 25, 2006 6:26 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [testing] locale dependent tests
>>>
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>> 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.
>>>>
>>>>
>>> I agree that we do not need the test cases like ABC_en_US_Test and
>>> ABC_ru_RU_Test. But I'm just wondering whether users could modify
the
>>> locale data. Would you please give some instructions? Thanks a lot.
>>>
>>
>> In Windows XP, open the Control Panel, choose "Date, Time, Language,
and
>> Regional Options" group and then click "Regional and Language
Options"
>> (if in Classic View, just click this option). On the Regional Options
>> tab click Customize button. A dialog opens. Here one can change
>> formatting options like decimal separator symbol, digit grouping
symbol,
>> date format, time format and others.
>>
>> I can't give you instructions for Linux but surely there should be a
way
>> to customize these data.
>>
>> I know for sure that in Russia many users customize decimal separator
to
>> be point like in English locale. This is because many programs had
>> problems dealing with something other than point in numbers. As far
as I
>> know the situation is better now.
>>
>>
>Thanks a lot for the detailed instructions, Alexey. But I don't think
>customizing Windows Locale setting will affect the behavior of Java
>application. And this change is only for current user. Am I wrong?
>

You're welcome. This change of course affects current user only.
I've tried to play with it. I've changed the settings and re-run tests
in DecimalFormatTest on the RI. Nothing's changed, they still fail. This
proves Java doesn't use system settings. However, it might be nice. If
user changed these settings, one can expect every application is to use
it.

>>>> 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.
>>>>
>>>>
>>> Not sure what the "fake" hard-coded locale is. I used to set the
>>>
>> default
>>
>>> locale to some particular one, e.g., en_US, but it seems that
someone
>>> (Tim) does not like the idea. :-)
>>>
>>>
>>
>> By "fake" locale I mean a locale that doesn't fetch any settings from
>> operating system. It may be en_US or another. However we should
ensure
>> the data in this locale can't be changed.
>>
>
>AFAIK,  Java will not read any locale information from the underlying
OS
>(Except Java will determine its default locale according to the current
>locale setting) . Java has its own locale mechanism. I'm not sure how
to
>implement the "fake" locale. Any comments? Thanks a lot.

You are right. I expected Java to use user settings for formatting.
Then we may test everything with one locale which is explicitly set in
tests. (Because Java locales can't be changed by a user. I also don't
know how to implement a "fake" locale. It was just an idea of
abstraction from locales with assumption they may be changed by user.
Since this is not the case, we don't need to invent a "fake" locale.)

>
>> If you had set en_US in the tests, we wouldn't have found bugs in
>> DecimalFormatter, for example HARMONY-965. All tests would have
passed
>> successfully in Russian locale as well.
>>
>So test cases for some special locales is necessary. Maybe we could
>leave it to ICU.

Sounds reasonable.


As for failing tests in DecimalFormatTest and ChoiceFormatTest, shall I
provide patches to make them pass?
I mean the tests with 'failing_' prefix and
ChoiceFormatTest.test_toPattern(). They still fail on my machine.


Thanks,
Alexey.

>
>> So we need to ensure that the logic is correct. How? It's a good
>> question. We could use non-standard data for a locale used for
testing,
>> and this may help. However I believe we can't find all bugs this way
>> too.
>>
>> App-driven Improvement proposed by Geir [1] can help with this.
>>
>> As another option, we can fetch data we expect to be used from
locale,
>> create strings to compare with using this data. [2] But this approach
>> will make tests almost unreadable.
>>
>> Thanks,
>> Alexey.
>>
>>
>>
>>
>>
>> --
>> 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
>>
>>
>>
>
>--
>Richard Liang
>China Software Development Lab, IBM

--
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


Mime
View raw message