0238-reliably-testing-async-pt1 (using @Published publishers to make tests deterministic)

[jjnino]

Hey @stephencelis & @mbrandonw Very interesting episode this week and something I have run into as well. I was wondering if y'all explored using the publisher on the @Published properties on the models to create expectations that can be awaited? I know it is not a great solution to the problem posed in the episode and would only really work for models that have @Published properties, but in the example of the fact going to nil or loading flipping to true, one could make the testing deterministic by introducing a subscriber to the @published properties subscriber. For example testFactIsLoading could be written as:

    func testFactIsLoading() async {
        let fact = AsyncStream.makeStream(of: String.self)
        
        let model = withDependencies {
            $0.numberFact.fact = { _ in
                await fact.stream.first(where: { _ in true })!
            }
        } operation: {
            NumberFactModel()
        }
        
        let loadingExpectation = expectation(description: "loading")
        
        let loadingCancellable = model.$isLoading.sink { val in
            if val {
                loadingExpectation.fulfill()
            }
        }
        
        model.fact = "An old fact about 0."
        
        let task = Task { await model.getFactButtonTapped() }
        await Task.yield()
        
        await fulfillment(of: [loadingExpectation])
        
        XCTAssertEqual(model.isLoading, true)
        fact.continuation.yield("0 is a good number.")
        await task.value
        XCTAssertEqual(model.fact, "0 is a good number.")
        XCTAssertEqual(model.isLoading, false)
    }

I think that would make it deterministic. Anyway, y'all probably have considered this already. I was curious if y'all thought this was a good approach? It can help with exhaustiveness but only works in some cases and feels clunky.

Thanks!

[stephencelis]

@jjnino Ha have you been reading our transcripts early? 😉

Combine absolutely allows us to write deterministic tests, and we'll be showing just that later in the series. But then the giant elephant in the room is why should we eschew Swift's modern concurrency tools whenever we want to write tests? Combine makes application code (and tests) a bit more complex, so ideally we would be able to use async-await and appreciate its benefits without sacrificing testability.

Also, judging from WWDC23, @Published doesn't appear to be long for this world (along with the Combine framework as a whole). Observability seems to be the path forward, though at the moment the tools it provides for observing a field are still pretty crude to use when compared to sink.

[jjnino]

Ha! 😜

Yes that is one large elephant and does make testing much more complex than it needs to be.

When y'all said y'all were using Xcode 15 Beta, I was actually curious why y'all didn't make the model @observable (not that is was relevant to the episode 😁).

Thanks for the reply! Excited to watch the rest of the series 👍

[stephencelis]

@jjnino The episode was long planned before Xcode 15, so exploring the new APIs would have delayed things a bit 😄

[jjnino]

Ah right makes sense! And of course it would have been easier for everyone to be able to use Xcode 14