Reliably testable Swift concurrency.
This library was designed to support libraries and episodes produced for Point-Free, a video series exploring the Swift programming language hosted by Brandon Williams and Stephen Celis.
You can watch all of the episodes here.
This library comes with a number of tools that make working with Swift concurrency easier and more testable.
The LockIsolated
type helps wrap other values in an isolated context. It wraps the value in a
class with a lock, which allows you to read and write the value with a synchronous interface.
The AnyHashableSendable
type is a type-erased wrapper like AnyHashable
that preserves the
sendability of the underlying value.
The library comes with numerous helper APIs spread across the two Swift stream types:
-
There are helpers that erase any
AsyncSequence
conformance to either concrete stream type. This allows you to treat the stream type as a kind of "type erased"AsyncSequence
.For example, suppose you have a dependency client like this:
struct ScreenshotsClient { var screenshots: () -> AsyncStream<Void> }
Then you can construct a live implementation that "erases" the
NotificationCenter.Notifications
async sequence to a stream:extension ScreenshotsClient { static let live = Self( screenshots: { NotificationCenter.default .notifications(named: UIApplication.userDidTakeScreenshotNotification) .map { _ in } .eraseToStream() // ⬅️ } ) }
Use
eraseToThrowingStream()
to propagate failures from throwing async sequences. -
Swift 5.9's
makeStream(of:)
functions have been back-ported. It can be handy in tests that need to override a dependency endpoint that returns a stream:let screenshots = AsyncStream.makeStream(of: Void.self) let model = FeatureModel(screenshots: { screenshots.stream }) XCTAssertEqual(model.screenshotCount, 0) screenshots.continuation.yield() // Simulate a screenshot being taken. XCTAssertEqual(model.screenshotCount, 1)
-
Static
AsyncStream.never
andAsyncThrowingStream.never
helpers are provided that represent streams that live forever and never emit. They can be handy in tests that need to override a dependency endpoint with a stream that should suspend and never emit for the duration of the test.let model = FeatureModel(screenshots: { .never })
-
Static
AsyncStream.finished
andAsyncThrowingStream.finished(throwing:)
helpers are provided that represents streams that complete immediately without emitting. They can be handy in tests that need to override a dependency endpoint with a stream that completes/fails immediately.
The library enhances the Task
type with new functionality.
-
The static function
Task.never()
can asynchronously return a value of any type, but does so by suspending forever. This can be useful for satisfying a dependency requirement in a way that does not require you to actually return data from that endpoint.For example, suppose you have a dependency client like this:
struct SettingsClient { var fetchSettings: () async throws -> Settings }
You can override the client's
fetchSettings
endpoint in tests to suspend forever by awaitingTask.never()
:SettingsClient( fetchSettings: { try await Task.never() } )
-
Task.cancellableValue
is a property that awaits the unstructured task'svalue
property while propagating cancellation from the current async context. -
Task.megaYield()
is a blunt tool that can make flakey async tests a little less flakey by suspending the current task a number of times and improve the odds that other async work has enough time to start. Prefer the reliability of serial execution instead where possible.
Some asynchronous code is notoriously difficult to test in
Swift due to how suspension points are processed by the runtime. The library comes with a static
function, withMainSerialExecutor
, that attempts to run all tasks spawned in an operation serially
and deterministically. This function can be used to make asynchronous tests faster and less flakey.
Warning: This API is only intended to be used from tests to make them more reliable. Please do not use it from application code.
We say that it "attempts to run all tasks spawned in an operation serially and deterministically" because under the hood it relies on a global, mutable variable in the Swift runtime to do its job, and there are no scoping guarantees should this mutable variable change during the operation.
For example, consider the following seemingly simple model that makes a network request and manages
some isLoading
state while the request is inflight:
@Observable
class NumberFactModel {
var fact: String?
var isLoading = false
var number = 0
// Inject the request dependency explicitly to make it testable, but can also
// be provided via a dependency management library.
let getFact: (Int) async throws -> String
func getFactButtonTapped() async {
self.isLoading = true
defer { self.isLoading = false }
do {
self.fact = try await self.getFact(self.number)
} catch {
// TODO: Handle error
}
}
}
We would love to be able to write a test that allows us to confirm that the isLoading
state
flips to true
and then false
. You might hope that it is as easy as this:
func testIsLoading() async {
let model = NumberFactModel(getFact: {
"\($0) is a good number."
})
let task = Task { await model.getFactButtonTapped() }
XCTAssertEqual(model.isLoading, true)
XCTAssertEqual(model.fact, nil)
await task.value
XCTAssertEqual(model.isLoading, false)
XCTAssertEqual(model.fact, "0 is a good number.")
}
However this fails almost 100% of the time. The problem is that the line immediately after creating
the unstructured Task
executes before the line inside the unstructured task, and so we never
detect the moment the isLoading
state flips to true
.
You might hope you can wiggle yourself in between the moment the getFactButtonTapped
method is
called and the moment the request finishes by using a Task.yield
:
func testIsLoading() async {
let model = NumberFactModel(getFact: {
"\($0) is a good number."
})
let task = Task { await model.getFactButtonTapped() }
+ await Task.yield()
XCTAssertEqual(model.isLoading, true)
XCTAssertEqual(model.fact, nil)
await task.value
XCTAssertEqual(model.isLoading, false)
XCTAssertEqual(model.fact, "0 is a good number.")
}
But that still fails the vast majority of times.
These problems, and more, can be fixed by running this entire test on the main serial executor.
You will also have insert a small yield in the getFact
endpoint due to Swift's ability to
inline async closures that do not actually perform async work:
func testIsLoading() async {
+ await withMainSerialExecutor {
let model = NumberFactModel(getFact: {
+ await Task.yield()
return "\($0) is a good number."
})
let task = Task { await model.getFactButtonTapped() }
await Task.yield()
XCTAssertEqual(model.isLoading, true)
XCTAssertEqual(model.fact, nil)
await task.value
XCTAssertEqual(model.isLoading, false)
XCTAssertEqual(model.fact, "0 is a good number.")
+ }
}
That small change makes this test pass deterministically, 100% of the time.
The latest documentation for this library is available here.
Thanks to Pat Brown and Thomas Grapperon for providing feedback on the library before its release. Special thanks to Kabir Oberai who helped us work around an Xcode bug and ship serial execution tools with the library.
Concurrency Extras is just one library that makes it easier to write testable code in Swift.
-
Case Paths: Tools for working with and testing enums.
-
Clocks: A few clocks that make working with Swift concurrency more testable and more versatile.
-
Combine Schedulers: A few schedulers that make working with Combine more testable and more versatile.
-
Composable Architecture: A library for building applications in a consistent and understandable way, with composition, testing, and ergonomics in mind.
-
Custom Dump: A collection of tools for debugging, diffing, and testing your application's data structures.
-
Dependencies: A dependency management library inspired by SwiftUI's "environment."
-
Snapshot Testing: Assert on your application by recording and and asserting against artifacts.
-
XCTest Dynamic Overlay: Call
XCTFail
and other typically test-only helpers from application code.
This library is released under the MIT license. See LICENSE for details.