withDependencies leaks all dependencies in standard test setup

[tcobb-dk]

Description

in some test setups, using withDependencies to mock dependencies results in any resources referenced in the dependencies closure being leaked. they are not released at the end of the test, and deinit is not called. for example:

func testLeak() {
    let parent = withDependencies {
        $0.child = ExampleChild(id: "test")
    } operation: {
        ExampleParent()
    }

    XCTAssertEqual(parent.id, "test")
}

after this test runs, the deinit in ExampleParent is called, the deinit in ExampleChild is not. this style of test setup, returning the constructed object from the operation and testing it externally, is used throughout the documentation. however:

func testLeak() {
    withDependencies {
        $0.child = ExampleChild(id: "test")
    } operation: {
        let parent = ExampleParent()
        XCTAssertEqual(parent.id, "test")
    }
}

after this test runs, the deinit in both types is called.

here's a minimal project reproducing this issue: DependenciesLeak.zip

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

dependencies are not leaked in either form

Actual behavior

dependencies are leaked in the first form

Steps to reproduce

1. run the test
2. breakpoint or log the deinit for each type
3. observe that only the parent is deallocated in the first form

Dependencies version information

1.4.1

Destination operating system

iOS 15

Xcode version information

Version 15.2 (15C500b)

Swift Compiler version information

swift-driver version: 1.87.3 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)
Target: arm64-apple-macosx14.0

[stephencelis]

@tcobb-dk Currently, dependencies are generally considered "static" interfaces, and so you shouldn't depend on any lifecycle guarantees for dependencies themselves. Dependencies attached to objects (like ExampleParent) are eventually freed, but this is done lazily via a garbage collection process, and so those dependencies will not be purged till another withDependencies call is made.

I'm going to convert this to a discussion since we don't consider it to be a bug, but it would be helpful to understand the issue you're having in your project with this behavior, and maybe we can help guide you to another solution.

[tcobb-dk]

is there some documentation you might be able to point me towards about the conditions under which dependencies get purged in tests (such to say, the rules for the garbage collector)? is it just the next withDependencies call?

in that case, would it be possible to introduce an api to manually purge the dependencies?

the use case is a network client that we'd like to mock in tests using URLProtocol (akin to this approach), so that our tests still exercise and catch bugs in the networking layer. implementing this mock requires some static storage on the URLProtocol subclass, since URLSession controls instantiation of that type.

what we'd like is if our mock network client registers its mocks on init and unregisters its mocks on deinit, but since deinit is not called, this instead has to be done in a more brittle way, through shared or per-example-explicit tearDown code.

furthermore, that dependencies aren't deallocated deterministically in tests, in accordance with normal automatic reference counting expectations, means that the running tests is insufficient to know if some code introduced a memory leak in one of the dependencies.

[tcobb-dk]

to elaborate a bit more, if in our tests we require some dependency to be released at the end of an example (unless there is a legitimate leak), it sounds like we could invoke withDependencies in some tear down step. is that correct?

if the library would prefer to garbage collect dependencies as the default, that's fine, but it'd be nice to have first-class support for invoking the garbage collection process manually, so that we can rely on it being supported. i don't think it's healthy for our tests to depend on the implicit garbage collection behavior of withDependencies to ensure test stability.