Does testing NavigationStack's destination view probably create memory leaks during testing?

[greenerchen]

Hi,

I'm learning SwiftUI, Swift concurrency, and trying TDD using ViewInspector. I use the code snippet[1] to detect possible memory leaks in my unit tests, and I found that the @ObservedObject property couldn't be released after test teardown. @ObservedObject property implies it's a MainActor instance, so my tests all annotate @MainActor to suppress the warnings of actor-isolated messages. I'm curious if I did the test wrong and how I can fix it. Thanks!

code snippets

1. memory leaks detection

func trackForMemoryLeaks(_ instance: AnyObject, file: StaticString = #filePath, line: UInt = #line) {
        addTeardownBlock { [weak instance] in
            XCTAssertNil(instance, "Instance should have been deallocated. Potential memory leak.", file: file, line: line)
        }
    }

2. system under testing (SUT)

@MainActor private func makeSUT(session: SHManagedSessionProtocol = SHManagedSessionMock()) -> MatchView {
        let matcher = ShazamMatcher(session: session)
        let sut = MatchView(matcher: matcher)
        trackForMemoryLeaks(matcher)
        return sut
    }

3. View using @ObservedObject

struct MatchView: View {
    @ObservedObject var matcher: ShazamMatcher
    @State private(set) var showResult: Bool = false
    var resultViewDidAppear: ((Self) -> Void)?
    
    var body: some View {
        NavigationStack {
            VStack {
                switch matcher.state {
                case .matched:
                    ShazamStartView()
                        .accessibilityIdentifier("match_idle_state_view")
                        .onTapGesture {
                            Task {
                                try await matcher.match()
                            }
                        }
                        .onAppear {
                            showResult = matcher.state == .matched
                            resultViewDidAppear?(self)
                        }
                ...
                }
                
            }
            .navigationDestination(isPresented: $showResult, destination: {
                if let result = matcher.currentMatchResult {
                    ShazamResultView(vm: ShazamResultViewModel(result: result))
                        .onAppear(perform: {
                            matcher.reset()
                        })
                        .accessibilityIdentifier("match_matched_state_view")
                }
            })
        }
    }
}

4. The test

@MainActor func test_state_matched() async throws {
        var sut = makeSUT()
        
        sut.matcher.state = .matched
        sut.matcher.currentMatchResult = ShazamMatchResult(match: matchStub)
        
        XCTAssertNoThrow(try sut.inspect().find(viewWithAccessibilityIdentifier: "match_idle_state_view"), "Expected to find the idle state view")
        
        let exp = sut.on(\.resultViewDidAppear) { view in
            XCTAssertTrue(try view.actualView().showResult)
            XCTAssertNoThrow(try view.actualView().inspect().find(viewWithAccessibilityIdentifier: "match_matched_state_view"))
            XCTAssertNoThrow(try view.actualView().inspect().find(text: "Way Maker"))
            XCTAssertNoThrow(try view.actualView().inspect().find(text: "Leeland"))
        }
        ViewHosting.host(view: sut)
        await fulfillment(of: [exp], timeout: 1)
    }

[nalexn]

Try to add ViewHosting.expel() at the end of the sut.on(\.resultViewDidAppear) inspection closure. Also, you might find it more convenient to use async inspection, as it handles the view expelling implicitly

[greenerchen]

Adding ViewHosting.expel() at the end of the sut.on(\.resultViewDidAppear) inspection closure works! async inspection looks nice. I'll give it a shot. Thank you!! :D

[greenerchen]

Just put a note here. After I use async inspection instead, it requires more resource to compile on my CI service (Bitrise M1 medium 4 CPU @ 3.2GHz, 6 GB RAM). With Bitrise Support's help, we've tested it needs Bitrise M1 Large 8 CPU @ 3.2GHz, 12 GB RAM) to compile successfully. Seems I can try another CI service.

[greenerchen]

I glanced the source code of ViewHosting.expel(), and found the design is to test and expel a single view. For my case, it was testing a NavigationStack's destination view. Seems this is the root cause why I encountered memory leaks.

[nalexn]

@greenerchen since you've reopened the ticket - what do you think should be done here? I thought after you added view expelling the memory issue was gone

[greenerchen]

@nalexn yes, the memory issue was gone on my laptop after I added view expelling. I wanna help update document about async inspection with NavigationDestination, so I reopened the ticket for the record.