[Seaside-dev] experience porting Grease-Tests to GNU Smalltalk

[Philippe Marschall]

2010/4/6 Paolo Bonzini <bonzini at gnu.org>:
> Hi all, Nicolas Petton and I finally got to porting Grease to gst and here
> are our impressions based on the failures we couldn't fix:

I feared it would be much worse ;-)

> 1) GRUtf8CodecTest>>#testCodecUtf8ShortestForm does not allow raising an
> exception.  What is the SUnit idiom for "raise an error or fail the
> assertion"?  Does this work:
>
>   self should: [self deny: (codec decode: abc) = 'ABC']
>        raise: Error
>
> ?

Looks fine at first glance.

> 2) GRStringTest>>#testCapitalizeUmlauts fails.  GNU Smalltalk intentionally
> does not do a half-hearted implementation of non-ASCII
> #asLowercase/#asUppercase.  One day it will be fully Unicode compliant, but
> for now it's just A-Z and a-z (7-bit ASCII).  Do we need this test?  I can
> XFAIL it of course, but I wonder what is really using #capitalized with
> umlauts.  All uses I can find in Seaside run it on a selector.

Seaside should send it only to ASCII strings, at least as long as
class names and selectors are limited to ASCII. However a ported
application (e.g. Pier) might not. If you can live with this
incompatibility you should be able to ignore this test.

> 3) GRCodecTest>>#testCodecLatin1Binary and
> GRUtf8CodecTest>>#testCodecUtf8Binary assume presence of a #binary method
> that apparently allows using ByteArrays instead of Strings. Again, is this
> method needed?  What is the spec, or can we remove the tests altogether?

Currently at least WAListenerAdaptor uses it.

> 4) Codec tests are a bit broken, in that they assume ISO-8859-1 is special
> in some way that I cannot really understand (and more so after the brief
> discussion of a few days ago).  In general, the tests must not assume that
> the literal 'Übèrstrîñgé' is expressed as ISO-8859-1,   as long as it is
> equal (#=) to whatever #decode: answers.  For example, gst literals use
> whatever is in the LC_ALL or LANG environment variables; typically UTF-8.

Hmm, that one feels familiar. Would a String class >> #streamContents:
and Character class >> #value: work better?

>  I'll test the changes I have here with Pharo and post a changeset on the
> bug tracker in a day or two.  In the meanwhile we can discuss items 1-3.

Thanks
Philippe