Reliably testing code that adopts Swift Concurrency?

[stephencelis]

@Joe_Groff

That's unfortunate. Like I said before, we should provide an API that lets code wait for the subscription to be ready before proceeding for testing purposes:

I'm not quite sure how that would work under the hood, but if this particular API could be fixed that'd be nice!

@Joe_Groff

If you were going to factor runTask into an AsyncStream transformation, though, then you could also make this easier to test by having the input stream a generic AsyncSequence instead of requiring it to be an NSNotification.Notifications sequence, which would let unit tests provide their own stream under their control.

I think this depends on any AsyncSequence<Element> throws/nothrows (or AnyAsyncSequence/AnyThrowingAsyncSequence) to be viable. Adding a generic per async sequence dependency to each view and view model becomes quickly untenable.

FWIW I've defined a helper that effectively uses Async(Throwing)Stream as type-erasers given an async sequence, so converting Notification.Notifications is a one-liner at least. It's just not as safe as it could be since the @rethrows effect can't be tracked right now.