> No, I mean that I looked a socket code to try to find examples to help me understand how they might have changed since the ancient scratch code I need to update, found that the #connect… methods now appear to include what used to be in the #waitForConn… type methods and then tried a bit of test code that seems not to be using the newer system.
>
> Since the newer code raises exceptions from the #connect… rather than simply setting the socket status, the test code opens a degugger. Now maybe some other test code in the unit test stuff does indeed handle the exception but I didn’t spot it. And the point remains that doing
> socket connect….
> socket waitUntil….
> will potentially do the wait timeout twice which seems unlikely to be what is wanted.

I assume that test code is testing a network-failure situation then?
So you just need to handle those exceptions for that test.  It's
definitely an improvement over setting socket status, but I do think
this expression:

self
waitForConnectionFor: timeout
ifTimedOut: [ConnectionTimedOut signal: 'Failed to connect in ',
timeout asString, ' seconds']
ifRefused: [ConnectionRefused signal: 'Failed to connect in ', timeout
asString, ' seconds']

is duplicated too much; they should all be calling
#waitForConnectionFor: instead.