Ivanov, Alexey A wrote:
-----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.
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.
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. :-)
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]
--
Richard Liang
China Software Development Lab, IBM
