Ivanov, Alexey A wrote:
-----Original Message-----
From: Richard Liang [mailto:[EMAIL PROTECTED]
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?
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.
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
