Overriding TestStore dependencies not working

[WedgeSparda]

Hi, have a question/problem trying to override my reducer dependencies via TestStore. First of all this is the way dependencies are injected into my component, is a bit weird since there are some peculiarities.

public final class MyComponent {

    let provider: DependencyProvider 
    private static var staticProvider: DependencyProvider!
    
    public init(with provider: DependencyProvider) {
        self.provider = provider
        Self.dependenciesProvider = provider
    }
}

extension MyComponent {

    enum AnExternalDependencyServiceKey: DependencyKey {
        static var liveValue: AnExternalDependencyService { staticProvider.externalDependencySecret }
    }

    // More dependencies...
}

extension DependencyValues {
    
    var anExternalDependencyService: AnExternalDependencyService {
        get { self[AuthExperience.AnExternalDependencyServiceKey.self] }
        set { self[AuthExperience.AnExternalDependencyServiceKey.self] = newValue }
    }

    // More dependencies...
}

Then are consumed into my reducer normally

struct MyReducer: ReducerProtocol {
    @Dependency(\.anExternalDependencyService) var anExternalDependencyService

    // More code and use of the dependency works great
}

Now, when writing my reducer unit tests, I do this

private let initialState: MyReducer.State = .init()
private var reducer: MyReducer!

override func setUp() {
    super.setUp()
    reducer = MyReducer()
}

func testSomething() async {

    let store = TestStore(initialState: self.initialState, reducer: self.reducer) {
        $0.anExternalDependencyService = AnExternalDependencyServiceMock()
    }
    // My assertions...

}

But test crashes with this error

Dependencies registered with the library are not allowed to use their default, live implementations when run from tests.

To fix, override 'anExternalDependencyService' with a test value. If you are using the Composable Architecture, mutate the 'dependencies' property on your 'TestStore'. Otherwise, use 'withDependencies' to define a scope for the override. If you'd like to provide a default value for all tests, implement the 'testValue' requirement of the 'DependencyKey' protocol.

If I try this approach, it fails too with the same message

func testSomething() async {

    let store = TestStore(initialState: self.initialState, reducer: self.reducer) 
    store.dependencies.anExternalDependencyService = AnExternalDependencyServiceMock()

    // My assertions...

}

And that's what I'm actually doing, right? Is there something wrong with my assumption or code? Have to use withDependecies despite using TCA?

Thanks for your time.

[tgrapperon]

Hey @WedgeSparda, it is possible that you're hosting your tests with the main app, and that this app is creating a store that accesses the dependencies, causing this kind of failure.

Otherwise, I'm not sure what's happening regarding the DependencyProvider, as involving reference types with dependencies can be tricky sometimes if some instance is "leaked" across dependencies boundaries/overrides. It looks like it should be fine in your case though.

Having the reducer stored as a property in your tests is a little odd too, but I guess you have your reasons to do so, and this is likely not what's causing the issue.

[WedgeSparda]

Hi @tgrapperon

Hey @WedgeSparda, it is possible that you're hosting your tests with the main app, and that this app is creating a store that accesses the dependencies, causing this kind of failure.

I didn't think about that, so I made a quick change to avoid use of @UIApplicationMain and rely on a main.swift, like explained here. But error is still happening. So it seems that's not the source of the problem.

Otherwise, I'm not sure what's happening regarding the DependencyProvider, as involving reference types with dependencies can be tricky sometimes if some instance is "leaked" across dependencies boundaries/overrides. It looks like it should be fine in your case though.

That's my only concern, but like I said, right now is the only proper way to inject dependencies in our current code base.

Having the reducer stored as a property in your tests is a little odd too, but I guess you have your reasons to do so, and this is likely not what's causing the issue.

If I instanciate the reducer at the same time as the TestStore nothing changes, so I think that's not the problem either.

[tgrapperon]

I would try the workaround mentioned in the documentation:

import SwiftUI
import XCTestDynamicOverlay

@main
struct MyApp: App {
  var body: some Scene {
    WindowGroup {
      if !_XCTIsTesting {
        // Your real root view
      }
    }
  }
}

This solution is more adapted to the problem of unimplemented dependencies being accessed by the hosting app. Basically, if you're running tests, the main app is empty.

[WedgeSparda]

Tried that too. Didn't work.

[tgrapperon]

Interesting. It would be great if you were able to extract a repro. It can be some escaping closure somewhere, but it's hard to tell without more info.
Alternatively, you can put a breakpoint in the testValue and check in which context this thing is called. It could give you a better picture of what's going on.

[mbrandonw]

Hi @WedgeSparda, can you share a project that reproduces the problem?

[tgrapperon]

Hey @WedgeSparda! There was likely an issue when committing your repro, as the project is merely an empty UIKit template at the moment.

[WedgeSparda]

@tgrapperon Sorry, my mistake, forgot to push. Now should be ok.

[tgrapperon]

Hey @WedgeSparda! You're linking ComposableArchitecture in MyFrameWork, DependenciesIssueTests, and DependenciesIssue (the app). This creates duplicate implementations, and this is likely causing issues when qualifying the dependency's KeyPath. The solution is to unlink ComposableArchitecture from the app and the test target and transitively rely on the version that is bundled with MyFramework. It is maybe possible that something can be done to alleviate this issue at the library level. I'm not sure.

You also need to adjust your test to run on MainActor, and assess that:

await store.send(.doSomething) {
  $0.result = "Executed MOCK Use Case"
}

for the test to pass.

[WedgeSparda]

@tgrapperon Wow, that was it!!!

This makes us rethink our dependencies on our project. We'll take a good look to that.

Also, don't know if there is something that can be done on the TCA framework to nitigate this, @mbrandonw

Thanks for your help.

[tgrapperon]

This is always a problem when working with dynamic frameworks and static libraries. The most "scalable" solution is probably to wrap TCA in its own dynamic framework, as it'd make the dependencies chain clearer. But there are probably a few gotchas and issues that come with this. See #1680 or #1774 for example.