harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [testing] locale dependent tests
Date Fri, 21 Jul 2006 10:33:51 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message