harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [build] status
Date Wed, 19 Jul 2006 04:33:41 GMT


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.

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_applyPatternLjava_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:
>>>>>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>>>>>> For additional commands, e-mail:
>>>>>>>> harmony-dev-help@incubator.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                               
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>                         
>>>>>>                   
>>>>>             
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>>         
>>>     
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>   
> 
> 

---------------------------------------------------------------------
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