[Seaside-dev] experience porting Grease-Tests to GNU Smalltalk
Philippe Marschall
philippe.marschall at gmail.com
Wed Apr 7 05:41:03 UTC 2010
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
More information about the seaside-dev
mailing list