aSCITestRunnerResult instead of test case when viewing test results written to stdout and GemStone?

[dalehenrich]

It seems the last time I ran a local GemStone test, we were getting a test case that displayed it's selector not the following:

TDShellFindCommandTests
 ✓ aSCITestRunnerResult (1448ms)
 ✓ aSCITestRunnerResult (2609ms)
 ✓ aSCITestRunnerResult (1479ms)
 ✓ aSCITestRunnerResult (2376ms)
 ✓ aSCITestRunnerResult (1077ms)
 ✓ aSCITestRunnerResult (46ms)
 ✓ aSCITestRunnerResult (2124ms)
 ✓ aSCITestRunnerResult (2655ms)
 ✓ aSCITestRunnerResult (895ms)
 ✓ aSCITestRunnerResult (13167ms)
 ✓ aSCITestRunnerResult (4199ms)
 ✓ aSCITestRunnerResult (43ms)
 ✓ aSCITestRunnerResult (32ms)
 ✓ aSCITestRunnerResult (24ms)

At this point I have no idea whether this is a general problem or restricted to GemStone ...

[dalehenrich]

The problem here appears to be that SCITestRunnerResult implements #prinString, but #title (used by ansiTitle for the SCITestReporterStdout) sends the message #asString. In GemStone, at least, #asString does not call #printString.... presumably #printString should be used in #title or (better) implement #asString ... since that appears to be the selector that is normally used ...

[dalehenrich]

Travis output is wrong as well ... have to expand the test result fold to see that the output is incorrect

[dalehenrich]

This problem showed up in the SmalltalkCI test, but noone bothered to actually look at the GemStone test output ... hard to write a unit test when you are changing the way test results output appears --- need to actually look at the results

[dalehenrich]

GemStone #printOn: calls #asString. Default #asString is the class name and default printString calls #printOn:

Pharo #printOn: is the class name. Default #asString calls #printString and default #printString calls #printOn:.

Ideally #printOn:, printString and #asString would return the same thing.

For Pharo implementing #printOn: unifies all three methods and for GemStone #asString unifies all three methods, therefore for portability Between GemStone and Pharo it is necessary to implement both #printOn: and #asString ...

I haven't looked at Squeak ...

[fniephaus]

Yes, I only realized that when I looked at the builds you mentioned yesterday.
I thought I had added some higher level tests for that but that's not the case I guess.
Will leave this open until we have some tests...