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

Frank Shearar frank.shearar at gmail.com
Tue Sep 4 19:54:37 UTC 2012


On 4 September 2012 15:58, Levente Uzonyi <leves at elte.hu> wrote:
> 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
> feature.
>
>> 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.

Ah, you'd said last time I nagged that the TestRunner's hanging onto
the TestCases that failed that hang onto obsolete classes left over
from the MC tests that SHOULD generate obsolete classes, if I recall
correctly?

I'm not sure I'd pin the blame entirely on TestRunner, but the PROPER
thing to do would be to run those kinds of tests - and Browser could
do with more tests like this - in a pristine Environment that could be
thrown away. In that Environment one could add/remove classes at will
without affecting external code.

>> Tests.Release.ReleaseTest.testUndeclared
>
>
> We should rewrite this to give more information, it doesn't fail on windows.
>
>
>>
>> - 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:\...).

Exactly: we can have reasonable confidence that 4.4 runs on Linux, but
right now there's no real evidence that it runs properly on _any_
other OS. (Because "but it works on MY machine" isn't really
evidence!)

frank

> Levente
>
>
>> 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