Container data-race when using concurrent tests

[cameroncooke]

We're using Swift-Testing which by default runs tests concurrently, our tests are also async meaning code under test can be suspended.

As an example, we have this dependency and mock version:

protocol SomeMockable {
    var name: String { get }
    func getName() async throws -> String
}

struct MyDependency: SomeMockable {
    let name = "Cameron"

    func getName() async throws -> String {
        let duration = UInt64(1 * 1_000_000_000)
        try await Task.sleep(nanoseconds: duration)
        
        return name
    }
}

struct MyDependencyMock: SomeMockable {
    let name = "Frank"

    func getName() async throws -> String {
        let duration = UInt64(1 * 1_000_000_000)
        try await Task.sleep(nanoseconds: duration)
        
        return name
    }
}

extension Container {
    var myDependency: Factory<SomeMockable> {
        self { MyDependency() }
            .scope(.singleton)
    }
}

And a sut:

final class MyController {
    @Injected(\.myDependency) var myDependency

    func getText() async throws -> String {
        let name = try await myDependency.getName()
        return "My name is \(name)"
    }
}

With the following swift-tests:

@Test
func getNameReturnsCameron() async throws {
    Container.shared.myDependency.register { MyDependency() }
    
    let sut = MyController()
    let name = try await sut.getText()
    
    #expect(name == "My name is Cameron")
}

@Test
func getNameReturnsFrank() async throws {
    Container.shared.myDependency.register { MyDependencyMock() }
    
    let sut = MyController()
    let name = try await sut.getText()
    
    #expect(name == "My name is Frank")
}

One of the two tests (random) will always fail:

The reason for failure is that the tests run in a single process, when the tests are executed concurrently one of the tests will register a dependency, and the other test will start concurrently and override this registration while the other test's await call is suspended. This leads to a data-race when registering and consuming the container.

I've included the example SPM package, you'll need Xcode 16 beta to be able to run the tests, and you'll also need to run the entire test case, they will pass when run individually.
test.zip

Is this a bug, or design flaw or is there a way to mitigate this without having to make the tests run serially?

[hmlongco]

Bug or design flaw? Depends on how you look at it I guess. Using shared containers in app works, primarily because the registrations occur at launch and remain stable while the app resolves its dependencies.

Switching to concurrent testing is at odds with the behavior of the application itself, which means that swapping out shared resources no longer works. This also breaks the various property wrappers that depend on the shared containers.

The only mitigation is running the tests serially, or rearchitecting the application to pass the container along as needed. That would allow you to construct and pass a correctly configured container to each concurrent instance under test.

[cameroncooke]

That's fair I guess. Of course, concurrent testing is just a mechanism to speed up test suites. But you're right there is only one application running at a time in a non-test scenario. I guess there is where the TaskLocal approach point-free use to scope dependencies would work better, though that has a load of gotchas of it's own.

[cameroncooke]

Might be worth highlighting this gotcha in the README given Swift-Testing is soon to be the default and tests run concurrent by default, you have to annotate then to run serially which we had to find out.