Re: gnustep-base tests

[Richard Frith-Macdonald]

> On 10 May 2016, at 23:29, Stefan Bidigaray <stefanbidi@gmail.com> 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.
> 
> Does anyone have any ideas on how to get manage write these tests to reflect 
> the intent? We want to make sure regressions aren't introduced in future 
> releases

I'm not familiar with the NSNumberFormatter tests, but just from reading 
through the testcases, it seems they are mostly working by looking at the 
format string produced by the formatter.
Perhaps it would make more sense to use the formatter to convert between 
NSNumber and NSString objects and test the results of those conversions, rather 
than looking at the format that's supposed to control the conversions?