[squeak-dev] Port numbers in network tests

Frank Shearar frank.shearar at gmail.com
Thu Apr 4 10:16:24 UTC 2013


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.

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

frank


More information about the Squeak-dev mailing list