Tim, Tests for DecimalFormat are not locale-specific. They fail because of the difference in the default data. I mean those five mentioned in the other thread (HARMONY-925). There's a problem with using DecimalFormatSymbols in this class which causes test_setDecimalFormatSymbolsLjava_text_DecimalFormatSymbols to fail. (This test is now excluded from running with 'failing' prefix; moreover the whole test class is excluded.) I logged this issue in HARMONY-965, and prepared a patch to fix the problem. Could you look at it?
As for failing test ChoiceFormatterTest.test_toPattern(), I've also attached a patch to HARMONY-925 which fixes the problem. Later today I'm going to create a patch for DecimalFormatTest. I think to set the locale to en_US, so that the result of formatting is the same as expected. What do you think about it? Still it has several other tests failing, and I can't figure out why. >-----Original Message----- >From: Tim Ellison [mailto:[EMAIL PROTECTED] >Sent: Tuesday, July 25, 2006 7:47 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [testing] locale dependent tests > >On 25/07/06, Richard Liang <[EMAIL PROTECTED]> wrote: ><snip> >> 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. :-) > >What I objected to was setting the locale to a specific value that >made the tests pass even where the logic is locale-specific. So, for >example, if an application using the ru_RU locale would experience the >problem that Alexey is seeing with the DecimalFormat, then the tests >should use the default locale, and we (Harmony) get the benefit of a >wide community of hetrogeneous testers. > >i.e. don't make all tests run on a uniform machine set-up -- let them >be realistic. Do you think we should always use the default locale, take the data from it, generate the result of formatting using these data, and then compare the strings? In my opinion, this will lead to almost unreadable tests? On the other hand, tests may still use the default locale until they proved to fail on some of the locales. And then we'll take a decision how to update test and whether we need an additional test for another locale. I mean, if necessary, we can create several tests for one method but with different locales, like en_US, ru_RU. Does it make sense? Thanks, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division > >Regards, >Tim > >-- > >Tim Ellison ([EMAIL PROTECTED]) >IBM Java technology centre, UK. > >--------------------------------------------------------------------- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
