Tim Ellison wrote:
Paulex Yang wrote:
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.
Agreed
If we can get agree on the above, so the i18n related test cases
organization are easier to judge: the logic is locale-independent,
Ah, that is why I was trying to determine. If the logic is
locale-independent then picking a locale to test with is ok; but it was
unclear that was the case when changing locale caused assertion failures.
I think the reason why most these kind of tests fail on different
locales is the test cases leverage some locale-dependent data, say, use
',' as separator of numbers or so, so it is the test's bug, to fix them,
we only need to specify a locale to the test.
so ideally the tests should be locale-independent, but we have some
exceptional cases, say, the en_UK in MessageFormat case,
Do you mean that in this case the logic /is/ locale dependent? I'm
confused again <g>.
And about the "exceptional case", say, the MessageFormat, the code is
still locale independent, but accidentally some different MessageFormat
in en_UK can have same behavior, it's still a data issue. But this data
issue is valuable here, please see the [1] for the MessageFormat's code
fragment used by toPattern(), in en_UK, the MessageFormat with "time,
long" pattern is always equals to the one with "time, full", so it never
returns ",time,full", the check order of RI only can be found in
en_UK(so far). So I called it "exceptional case".
[1]MessageFormat fragment
if (format.equals(DateFormat
.getTimeInstance(DateFormat.DEFAULT, locale))) {
buffer.append(",time");
} else if
(format.equals(DateFormat.getDateInstance(DateFormat.DEFAULT,
locale))) {
buffer.append(",date");
} else if
(format.equals(DateFormat.getTimeInstance(DateFormat.SHORT,
locale))) {
buffer.append(",time,short");
} else if
(format.equals(DateFormat.getDateInstance(DateFormat.SHORT,
locale))) {
buffer.append(",date,short");
} else if (format.equals(DateFormat.getTimeInstance(DateFormat.LONG,
locale))) {
buffer.append(",time,long");
} else if (format.equals(DateFormat.getDateInstance(DateFormat.LONG,
locale))) {
buffer.append(",date,long");
} else if (format.equals(DateFormat.getTimeInstance(DateFormat.FULL,
locale))) {
buffer.append(",time,full");
} else if (format.equals(DateFormat.getDateInstance(DateFormat.FULL,
locale))) {
buffer.append(",date,full");
} else {
buffer.append(",date,");
return ((SimpleDateFormat) format).toPattern();
}
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.
Right, I don't think we need to have test_en_US blah, unless perhaps we
pick one as the base for locale-dependent tests, otherwise we just run
all tests in the machine default locale.
Regards,
Tim
--
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]
