How to handle stream response async - swift

Question

I opened a stream to a server I have. When I send the text "PING" it responds with "PONG". I have successfully connected, sent messages, and received responses. I have a pretty bare bones test below.
The Problem
I want to handle the messages from the server as they come in. Currently, I send three PINGs and later I get three PONGS. The server responds with PONG immediately after but my code is not handling the response until after the main thread completes. The expected result is to see the PONG messages immediately after the PING is sent because they are being handled concurrently.
What I tried
Pretty much, what you see below. I thought "I want to handle the stream responses at the same time as sending messages so I'll need to do that on another thread". So, I put the RunLoop in another thread via GCD. That did not help....Can't figure our how to make the StreamDelegate handle its delegate method stream in a separate thread...
Current Console Result
PING
PING
PING
PONG
PONG
PONG
Desired Console Result
PING
PONG
PING
PONG
PING
PONG
The Code
import Foundation
import XCTest
class StreamTests: XCTestCase, StreamDelegate {
var inputStream: InputStream?
var outputStream: OutputStream?
let url: URL = URL(string: "http://theserver.com:4222")!
func testAsyncStream() {
self.setupStream()
let ping = "PING".data(using: String.Encoding.utf8)!
print("PING")
self.outputStream?.writeStreamWhenReady(ping)
sleep(1)
print("PING")
self.outputStream?.writeStreamWhenReady(ping)
sleep(1)
print("PING")
self.outputStream?.writeStreamWhenReady(ping)
sleep(1)
}
private func setupStream() {
guard let host = url.host, let port = url.port else { print("Failed URL parse"); return }
var readStream: Unmanaged<CFReadStream>?
var writeStream: Unmanaged<CFWriteStream>?
CFStreamCreatePairWithSocketToHost(nil, host as CFString!, UInt32(port), &readStream, &writeStream)
self.inputStream = readStream!.takeRetainedValue() as InputStream
self.outputStream = writeStream!.takeRetainedValue() as OutputStream
guard let inStream = self.inputStream, let outStream = self.outputStream else { return }
inStream.open()
outStream.open()
DispatchQueue.global(qos: .utility).sync { [weak self] in
for stream in [inStream, outStream] {
stream.delegate = self
stream.schedule(in: .current, forMode: .defaultRunLoopMode)
}
RunLoop.current.run(mode: .defaultRunLoopMode, before: Date.distantFuture)
}
}
func stream(_ aStream: Stream, handle eventCode: Stream.Event) {
switch aStream {
case inputStream!:
switch eventCode {
case [.hasBytesAvailable]:
print("PONG")
break
default:
break
}
default:
break
}
}
}

Answer 1

Don’t try to write unit tests for multithreaded code. It will bite you in the ass later.
The reason unit testing code that runs on multiple threads is hard is the fact that you can’t control the order of execution of threads, nor the allocated time per thread – this is an OS decision.
Thus, in order to make sure the code submitted on the other thread executes and populates the expected data, you’ll need to block the main thread, where unit tests usually runs, for an amount of time large enough to be sure the other thread finishes the work.
Now, the tricky part is to find what that amount of time should be. Make it too short and you’ll see random failures of your unit tests, make it too long and you’ll increase the duration of your unit tests more and more. And theoretically there’s no upper limit for how long will need to wait for the other thread to finish, as this is out of our control (remember, the OS decides which thread to pick up next and how much time to allocate to it).
And worse, when a unit test like this starts failing on a CI machine but it doesn’t fail on your machine, who’s to blame: the CI machine for being too slow, or your code misbehaving in some conditions that happen only on the CI machine? This ambiguity can lead to lot of time wasted in trying to figure out what the hack happens with the tested code.
Conclusion: don’t try to write unit tests for code that executes parts of its work on a different thread. The reason is simple: robust unit tests need to have control over all inputs of the tested code, and the second thread is not something it can control (unless you mock the thread dispatching, but that’s another story).
Instead, push as much logic as you can into single-thread methods, and tests those methods instead. In the end, most of the bugs occur due to incorrect business logic.