> On 10 May 2016, at 23:29, Stefan Bidigaray <[email protected]> wrote:
>
> I feel like I'm having deja vu. We spoke about this a few months back. The
> issue is that the ICU's "display" functions are not guaranteed to have a
> stable output. Makes sense, because languages and conventions change over
> time.
>
> This issue is unrelated to this problem. Without looking at the code and
> going only off memory, the issue has to do with the fact that we're testing
> for a particular behavior, but ICU changed since the test was written. It's
> tough writing tests for ICU, because there are no guarantees anywhere. The
> only guarantee is that a human being will be able to interpret it. The ICU
> output changed some time around version 4.4 or 48.
>
> Still, these shouldn't be a "hopeful" just because the tests should always
> pass, a (nil), for example, is not acceptable.
I think we have actually only seen two different formats from the ICU library.
So I took the simple option to allow both;
/* Different versions of ICU use different formats, so we need to
* permit alternative results.
*/
str = [fmt stringFromNumber: num];
PASS([str isEqual: @"(R$1.235)"] || [str isEqual: @"_R$1.235"],
"negativeFormat used for -ve number");
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
