[squeak-dev] Failing tests in trunk, gearing up for 4.4 release

Levente Uzonyi leves at elte.hu
Tue Sep 4 14:58:51 UTC 2012

On Tue, 4 Sep 2012, Frank Shearar wrote:

> Hi,
> I meant to nag a lot more about the failing tests, and I haven't.
> Sorry for not being sufficiently annoying!
> We still have a bunch of failing tests -
> KernelTests.Chronology.TimeStampTest.testFromSeconds

It's an issue with the timezones again (UTC vs local). I vaguely 
recall Chris Muller saying that TimeStamp should be removed or so.

> CollectionsTests.Streams.RWBinaryOrTextStreamTest.testExisiting

This one should be expected failure since it's testing a non-existing 

> KernelTests.Chronology.TimeStampTest.testReadFromA1

Same as #testFromSeconds.

> NetworkTests.Kernel.SocketTest.testSendTimeout

This is something related to the new network code. With Network-ul.136 the 
likeliness of this happening got a lot lower. I started debugging this 
when I found that the variable got added back to the image. This doesn't 
fail in Squeak 4.3 btw. But it fails on windows too in 4.4.

> Tests.Localization.LocaleTest.testLocaleChanged

This is something related to the GetText integration, should be debugged.

> Tests.Monticello.MCFileInTest.testStWriter
> Tests.Monticello.MCMczInstallerTest.testInstallFromFile
> Tests.Monticello.MCMczInstallerTest.testInstallFromStream

Old MC bugs, to be debugged.

> Tests.Release.ReleaseTest.testNoObsoleteClasses

It's the TestRunner's fault.

> Tests.Release.ReleaseTest.testUndeclared

We should rewrite this to give more information, it doesn't fail on 

> - and I'd really like them to be green for a release. The Monticello
> tests cause noise, and so the ReleaseTests should pass if we don't run
> the MC tests. The SocketTest is, as I understand it, an issue specific
> to Linux, and doesn't occur on Window.
> If I _have_ to, I'll move the tests into "expected failures", and
> re-enable them when we start work on 4.5.
> One big gap in our testing infrastructure is testing on non-Linux
> platforms. I would like a kind soul to take up CI-like duties and

On windows, FileDirectoryTest >> #testRelativeNameIfAbsoluteFor is 
failing (with an error), because FileDirectory >> 
#relativeNameIfAbsoluteFor: is assuming that the full path begins with a 
path delimiter, but this is not true on windows, since the first character 
is the drive letter there (C:\...).


> commit to run the entire suite on OS X and Windows reasonably often.
> Any takers? (Ideally we'd have build slaves for this, but...)
> frank

More information about the Squeak-dev mailing list