> -----Original Message----- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Paulex Yang wrote: > > I think Richard's patch is fine, i.e., specify a locale to the test, > > what we want to test is toPattern()'s logic, not the locale data or > > something, and the specified locale is OK to test the logic. And I also > > think maybe one locale is not enough, so we may want to include some > > more exceptional locale, say, en_UK in this case, by which, we can try > > to follow RI as possible. Loose the test by removing the assertion here > > is dangerous, just like any other cases without clear spec. > > I think what this proved to us is that our testing matrix must include > WinXP en_US, en_UK, en_RU etc.
Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. -Nathan > > IOW, we want to run our test suite on as many locale's as possible, and > have it pass on every one of them. We may choose local-specific tests, > btw, which is what I think you are suggesting. > > geir > > > > > > > Geir Magnusson Jr wrote: > >> What do you suggest then? > >> > >> Paulex Yang wrote: > >> > >>> Geir Magnusson Jr wrote: > >>> > >>>> Then I guess we just fix the test. > >>>> > >>> Agree, just think we should not "fix" the test by removing the > >>> assertion. > >>> > >>>> geir > >>>> > >>>> > >>>> Paulex Yang wrote: > >>>> > >>>> > >>>>> Tim Ellison wrote: > >>>>> > >>>>>> Geir Magnusson Jr wrote: > >>>>>> > >>>>>> > >>>>>>> Now, on my windows box I got a clean build, no failures.... hm. > >>>>>>> > >>>>>> The test works on en_US locale and fails on en_UK. I'm guessing > that > >>>>>> your machine is set up as en_US. > >>>>>> > >>>>>> Richard offered a patch that sets the locale to en_US for all > >>>>>> MessageFormatTest-s, but I suggested that was not a suitable > >>>>>> solution. > >>>>>> > >>>>>> For now I suggest we remove the assertion, since it is beyond the > >>>>>> spec > >>>>>> requirements for this type. > >>>>>> > >>>>> Tim, > >>>>> > >>>>> Should we also consider the principle of "follow the RI" here? I > >>>>> think > >>>>> it is a sample of unclear spec, and we should assert if our > >>>>> implementation follows RI, i.e., the assert about return value of > >>>>> toPattern() is necessary. The issue here is just that the testcase > >>>>> assumes the return value is locale-independent, so I think Richard's > >>>>> patch is OK. Further, from the test perspective, maybe(just maybe) > >>>>> test > >>>>> case on only one locale is not enough to check Harmony's toPattern() > >>>>> logic, tests on more different locale(especially the 'exceptional' > >>>>> case > >>>>> like en_UK) are better. > >>>>> > >>>>> Also FYI, I tried the original test case with RI on en_UK locale, > >>>>> and it > >>>>> failed exactly as Harmony. > >>>>> > >>>>>> Regards, > >>>>>> Tim > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Geir Magnusson Jr wrote: > >>>>>>> > >>>>>>>> This is nuts. We need to chase down the commit that broke this, > >>>>>>>> and > >>>>>>>> reverse it. We can't have a broken build persisting this long. > >>>>>>>> > >>>>>>>> geir > >>>>>>>> > >>>>>>>> > >>>>>>>> Tim Ellison wrote: > >>>>>>>> > >>>>>>>>> (1) Linux build/tests are passing again, but for some reason the > >>>>>>>>> 'BUILD SUCCESSFUL' note didn't go to the commit list? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> (2) Windows build/test is still failing with: > >>>>>>>>> > >>>>>>>>> Wrong full date pattern expected:<...full...> but > was:<...long...> > >>>>>>>>> > >>>>>>>>> junit.framework.ComparisonFailure: Wrong full date pattern > >>>>>>>>> expected:<...full...> but was:<...long...> at > >>>>>>>>> > org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter > nLjava_lang_String(MessageFormatTest.java:244) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> at > >>>>>>>>> > java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Tim > >>>>>>>>> > >>>>>>>>> > >>>>>>>> ----------------------------------------------------------------- > ---- > >>>>>>>> > >>>>>>>> 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: harmony-dev- > [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: harmony-dev- > [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] > >> > >> > >> > > > > > > --------------------------------------------------------------------- > 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]
