Dependency testValue Not Overridden

[TicTocCroc]

Description

Problem

Dependencies do not get properly overridden when testing a specific sequence of actions and effects.

Below I have a simple reducer that has an onAppear action that triggers a fetchValue action. This action in turn produces an effect that uses a ValueClient dependency to fetch a value, whose result is delivered with a valueResponse action.

However, when I run the test below, making sure to override the dependency as shown in the documentation, the test always fails with the failure testValueOnAppear(): Unimplemented.

It seems that the dependency override does not persist during the effect returned by the fetchValue action. Maybe I'm not setting up my dependency correctly, or not using effects correctly?

Reducer

struct ValueReducer: ReducerProtocol {
  struct State: Equatable { var value: Int = 0 }
  
  enum Action: Equatable {
    case onAppear
    case fetchValue
    case valueResponse(TaskResult<Int>)
  }
  
  @Dependency(\.valueClient) var valueClient
  
  func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
    case .onAppear:
      return .task { return .fetchValue }
    case .fetchValue:
      return .task {
        await .valueResponse(TaskResult { try await valueClient.fetch() } )
      }
    case let .valueResponse(.success(value)):
      state.value = value
      return .none
    case .valueResponse(.failure): return .none
    }
  }
}

Dependency

struct ValueClient {
  var fetch: @Sendable () async throws -> Int
}

extension ValueClient {
  static let live = Self(fetch: { return 0 })
  
  static let preview = Self(fetch: { return 0 })
  
  static let test = Self(fetch: unimplemented(placeholder: 0))
}

private enum ValueClientKey: DependencyKey {
  static let liveValue = ValueClient.live
  static let previewValue = ValueClient.preview
  static let testValue = ValueClient.test
}

extension DependencyValues {
  var valueClient: ValueClient {
    get { self[ValueClientKey.self] }
    set { self[ValueClientKey.self] = newValue }
  }
}

Failing Test

final class ValueTests: XCTestCase {
  func testValueOnAppear() async {
    let store = TestStore(initialState: ValueReducer.State(), reducer: ValueReducer())
    
    store.dependencies.valueClient = ValueClient(fetch: { 1 })
    
    await store.send(.onAppear)
    await store.receive(.fetchValue)
    await store.receive(.valueResponse(.success(1))) {
      $0.value = 1
    }
  }
}

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

I expect the overridden ValueClient dependency to be used during the effect while running the test, causing the test to pass.

Actual behavior

The unimplemented version of the dependency is used instead, and the test fails.

Steps to reproduce

Running the single unit test in this Xcode project should recreate the issue.

The Composable Architecture version information

0.45.0

Destination operating system

iOS 16.1

Xcode version information

14.1 (14B47b)

Swift Compiler version information

swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-5.7.1.135.3 clang-1400.0.29.51)
Target: arm64-apple-macosx13.0

[tgrapperon]

Hey @TicTocCroc. I've just tried and your test is passing on my machine (albeit I had to annotate the ValueTests class as @MainActor).
Can you try to reproduce the issue in a standalone app?

[TicTocCroc]

I linked an Xcode project in the "Steps to reproduce" section that recreates the problem for me.

[TicTocCroc]

Nevermind. I see the project I linked is incomplete for some reason. Here's another that should reproduce the issue.

Value.zip

[tgrapperon]

Ah sorry, I didn't see. Indeed, a few files were missing, but I was able to reproduce the issue with your project by filing the gaps.
I'm wondering if this is not related the the recent #1640, because the following equivalent code does pass when copy passed in a TCA project:

struct ValueReducer: ReducerProtocol {
  struct State: Equatable { var value: Int = 0 }
  
  enum Action: Equatable {
    case onAppear
    case fetchValue
    case valueResponse(TaskResult<Int>)
  }
  
  @Dependency(\.valueClient) var valueClient
  
  func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
    case .onAppear:
      return .task { return .fetchValue }
    case .fetchValue:
      return .task {
        await .valueResponse(TaskResult { try await valueClient.fetch() } )
      }
    case let .valueResponse(.success(value)):
      state.value = value
      return .none
    case .valueResponse(.failure): return .none
    }
  }
}

import XCTestDynamicOverlay

struct ValueClient {
  var fetch: @Sendable () async throws -> Int
}

extension ValueClient {
  static let live = Self(fetch: { return 0 })
  
  static let preview = Self(fetch: { return 0 })
  
  static let test = Self(fetch: unimplemented(placeholder: 0))
}

private enum ValueClientKey: DependencyKey {
  static let liveValue = ValueClient.live
  static let previewValue = ValueClient.preview
  static let testValue = ValueClient.test
}

extension DependencyValues {
  var valueClient: ValueClient {
    get { self[ValueClientKey.self] }
    set { self[ValueClientKey.self] = newValue }
  }
}

@MainActor
final class ValueTests: XCTestCase {
  func testValueOnAppear() async {
    let store = TestStore(initialState: ValueReducer.State(), reducer: ValueReducer())
    
    store.dependencies.valueClient = ValueClient(fetch: { 1 })
    
    await store.send(.onAppear)
    await store.receive(.fetchValue)
    await store.receive(.valueResponse(.success(1))) {
      $0.value = 1
    }
  }
}

[mbrandonw]

@tgrapperon Are you saying that by putting everything in a single file it works, or is there some other change you made?

[tgrapperon]

This one is more subtle than #1640 in any case: If we copy/paste the reducer/dependencies in the test target, and if remove the @testable import Value, it doesn't pass. If we delete the reducer/dependency from the app and replace the view by Color.red, it starts to pass without having to touch the test that wasn't importing this anymore anyway.
This is quite interesting. I'll try to reproduce with a SwiftPM.

[tgrapperon]

@mbrandonw More precisely:

• Everything in the test target, nothing in the app -> Pass
• Everything in the test target, everything in the app (but not imported in the test) -> Fail
• Nothing in the test target, everything in the app (standard setup) -> Fail

(by "Everything", I mean the "Reducer+Dependency" declarations)

[mbrandonw]

Oh, I think this is simpler than #1640. I think it's just the app running in the simulator while the test is running. 🙄

If you comment out the view in the WindowGroup it works. So this is just a case of the simulator polluting the test, which is always a problem in iOS applications.

[TicTocCroc]

I see. I originally tried to set up the test target to run without the host application, as I saw in one of the TCA episodes, but I couldn't get it working. Then I saw that the sample applications in TCA still run the hosting application, so I thought maybe that's no longer possible.

Is it still possible to run the test target without the hosting application?

[mbrandonw]

@TicTocCroc I don't think tests can be run without a hosting application. But the tricks I shared below could help. There may be better ideas though.

[TicTocCroc]

Hmm, thinking back, the episode I saw may have isolated the feature code to its own framework or module shared between the host and test targets. Then perhaps the test target could run without its host?

[tgrapperon]

When using SwiftPM to modularize your features, it can run tests without an explicit host AFAIK.

[mbrandonw]

I'm going to convert this to an issue because it's not a bug per-se with the library, but rather a quirk of how testing works in iOS. If you didn't know, when you run tests for iOS, Xcode launches a simulator with your app. This means the entry point of your application will start executing even if it has nothing to do with the tests you are running.

One work around would be doing something like this in the entry point:

@main
struct ValueApp: App {
  var body: some Scene {
    WindowGroup {
      ValueView(
        store: Store(
          initialState: ValueReducer.State(),
          reducer: ValueReducer()
            .dependency(\.context, .live)
        )
      )
    }
  }
}

Or you could just omit your entry point from the application when running in tests by using XCTestDynamicOverlay:

import XCTestDynamicOverlay

@main
struct ValueApp: App {
  var body: some Scene {
    WindowGroup {
      if !_XCTIsTesting {
        ValueView(
          store: Store(
            initialState: ValueReducer.State(),
            reducer: ValueReducer()
          )
        )
      }
    }
  }
}

Would be curious to hear if others have more ideas.

[tgrapperon]

Very interesting! I wasn't aware of this phenomenon.
One solution would be to provide a WindowGroup initializer that would take care of that. That seems overkill to simply do that for testing, but it may find additional uses like storing the root Store instance (still not clear if this is required at this level), handling multiple windows if windowed presentation is included into navigation, creating namespaced effect identifiers for document-based apps, or other app-wide features that could make sense for TCA.

[gcohen-dev]

While I agree with the term it's not a bug per-se with the library, I do think this is something we expect from the library.
Currently, all my tests are failing in a huge modularize app.

[tgrapperon]

@gcohen-dev Do you modularize using SwiftPM? AFAIK, this issue shouldn't happen when running SwiftPM tests, as a generic host is then automatically provided to perform them.

The situation should be improved with the next update of TCA, but in the meantime, you can probably define a ViewModifier that would implement @mbrandonw suggestion:

import XCTestDynamicOverlay
extension View {
  public func bypassWhenTesting() -> some View {
    self.modifier(XCTestBypass())
  }
}
struct XCTestBypass: ViewModifier {
  func body(content: Content) -> some View {
    if !_XCTIsTesting {
      content
    }
  }
}

You then active it using:

@main
struct ValueApp: App {
  var body: some Scene {
    WindowGroup {
      ValueView(
        store: Store(
          initialState: ValueReducer.State(),
          reducer: ValueReducer()
        )
      )
      .bypassWhenTesting()
    }
  }
}

This should prevent your dependencies from being accessed by the host app.

[gcohen-dev]

While most of the features are modularized, we still have some features that are in the host app since we started using a composable a year ago and not all the team have did the adjustments.
We are now in the middle of refactoring to reducer protocol and modularization is the next thing.

[mbrandonw]

@gcohen-dev This should be fixed in 0.47.2. Please let us know if you have any problems.

[mbrandonw]

@gcohen-dev The next release of TCA will fix this problem. See #1686.