Re: gnustep-base tests

[Stefan Bidigaray]

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.

Regards

On May 10, 2016 18:15, "Eric Heintzmann" <heintzmann.eric@free.fr> wrote:

Le 10/05/2016 11:41, Richard Frith-Macdonald a écrit :

On the one hand, the particular number format stuff is rarely used, so a bug there may not be important (and may depend on the particular ICU library shipped on the system).

Well I ve done some tests and this particular problem is common to debian testing (stretch)  and unstable (sid) and Ubuntu 16.04 too...

On the other, we really want to fix *any* failure of the regression tests.
Does the same problem occur with gnustep-base from svn trunk?
Can you get a stack trace of the crash?

Well I ve tried to use gnustep-make 2.6.6-3 to build gnustep-base 1.24.9 and the regrssesion test ar ok !!
It seem the bug is in gnustep-make 2.6.8 (or in the packaging)

Thanks
Eric

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep