[Seaside] Pharo/Seaside UI testing
tony.fleig at gmail.com
Sat Jan 22 18:41:10 UTC 2011
Thanks yet again Sven!
I have made all the changes you suggested.
However, one test fails in my environment after switching to the Zinc
Seaside adaptor: the TLTest>>#testForgotUsername test. This test is
not very different from all the other tests that pass and of course it
passes using the WAKom server. I have no idea why only this test is
Its failing on to a ConnectionTimedOut error in Socket>>#waitForData
processing a ZnClient>>#post:data: request. This is reproducible in
OSX SnowLeopard, but it does not occur at all in Ubuntu Linux 9.10 or
Windows 7. I doubled the timeout period, but all that did was cause me
to wait longer for the error.
If you want to investigate this, you can use the latest TF-Login (and
TF-Login-Tests) package from Squeaksource. Change the method
TLTest>>#useZincServer to return true to use the Zinc server.
If you don't have access to a Mac, I suppose I can investigate further here.
On Fri, Jan 21, 2011 at 3:02 AM, Sven Van Caekenberghe <sven at beta9.be> wrote:
> On 20 Jan 2011, at 22:01, Tony Fleig wrote:
>> Thanks Sven!
>> I have updated my test code and uploaded the new version to Squeaksource and updated the blog entry to reflect the changes as well.
>> I'll look at using the Zinc Seaside adaptor was well.
>> (It'd be nice to have the tests run regardless of whether there was already a Seaside server up and running.)
> Here you go (all instance methods on TLTest):
> I removed the port inst var and #port and #port:. (existingPort and wasRunning could also be removed)
> I added a server instance variable and #server and #server:.
> ^ ZnZincSeasideAdaptor
> ^ 'http://localhost:', self server port asString
> self server: (self seasideAdaptorClass port: 12345) start.
> self assert: (self server isRunning ) description: 'This test needs a Seaside server.'.
> self server unregister
> The only 'disadvantage' is that the server is started/stopped for each test (method) but that is part of the idea of SUnit (start each test with fresh objects). I believe there exists something like a shared testing resource but I have never used it.
> PS: some other constructive remarks:
> - it is better to move the unit tests and related code (like the test app) to a testing package (your test suite is big enough to stand on its own, it gives users the option to skip the tests in deploy images, unclutters the packages, besides, the automatic app install in not always wanted)
> - the documentation workspace is very impressive, however opening it automatically is a deal breaker on headless images (where one can load newer versions using MC and a web interface)
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside