[squeak-dev] Re: Port numbers in network tests

Frank Shearar frank.shearar at gmail.com
Thu Apr 4 12:30:01 UTC 2013


On 4 April 2013 11:16, Frank Shearar <frank.shearar at gmail.com> wrote:
> So this isn't exactly a common use case, except on build.squeak.org:
>
> You have a bunch of network tests, so in your #setUp you start up a
> server on some port and in #tearDown you shut down the server. What
> port do you use? Well, it doesn't really matter too much, as long as
> the port's available. So you choose some probably-not-used port, like
> 7799. (WebClient's test suite uses this.) All is almost always well,
> because tests only fail when something's using 7799, which is almost
> never.
>
> build.squeak.org has two executors, which means it can run two builds
> concurrently. Suddenly, if you build SqueakTrunk, you'll trigger
> ExternalPackages, ExternalPackages-Squeak4.3 and External-Squeak4.4.
> Which means you will often execute the same test suite in different
> images at the same time. Suddenly those tests using a hard-coded port
> all fail, causing noise. (Xtreams' test suite is also vulnerable to
> this problem: look at the  XTSocketReadingWritingTest failures in
> http://build.squeak.org/job/ExternalPackages/43/testReport/)
>
> So what do we do?
>
> One approach that I can think of is, like WebClient's test suite, to
> use a method #port returning the port to use in a test. However, #port
> should not return a constant but rather attempt to open a port within
> some range, and return _some_ open port. The problem here is a
> time-of-check-time-of-use race.

In particular, this doesn't break any tests (but haven't yet verified
that it works for the above use case!):

port
    | freePort socket |
    port ifNotNil: [^ port].
    freePort := 7766.
    socket := Socket newTCP.
    [[socket listenOn: freePort.
    freePort := freePort + 1.
    socket isWaitingForConnection] whileFalse]
        ensure: [socket destroy].
    ^ port := freePort.

where port is a new instvar that allows us to remember the free port
we just found. Note that this only works because of TestCase's (too)
broad remit; one TestCase instance runs one test.

frank

> Now that might nearly always work. Can anyone think of a better method?
>
> frank


More information about the Squeak-dev mailing list