Change the dependency (via init injection) on the fly in the unit test

[jeffersonsetiawan]

Hi, I really love this architecture, I've used the TCA since the day 1.

Since the release of ReducerProtocol, I've experience "possible" difficulty on changing the dependency on the fly in a single unit test flow.

In ReducerProtocol, we have 2 differents way to inject our dependency/environment. First is from Dependency property wrapper, and the other one is inject it on the init (more like the old environment style of original TCA)

Let see this example code in the original style of TCA:

struct MyState {
  var content: Int
  var error: MyError?
}

enum MyError: Error {
  case serverError
}

enum MyAction {
  case didLoad
  case receiveData(Result<Int, MyError>)
  case didTapTryAgain
}

struct MyEnvironment {
  var loadData: () -> Effect<Result<Int, MyError>>
}

let myReducer = Reducer<MyState, MyAction, MyEnvironment> { state, action, env in 
  switch action {
    case .didLoad, .didTapTryAgain:
      state.error = nil
      return env.loadData()
        .map(MyAction.receiveData)
    case let .receiveData(result):
      switch result {
        case let .success(number):
          state.content = number
        case let .failure(error):
          state.error = error
      }
      return .none
  }
}

// Test

func testTryAgainAfterErrorLoadingPage() {
  let testStore = TestStore(
    initialState: MyState(),
    reducer: myReducer,
    environment: MyEnvironment.mockFailed
  )

  testStore.send(.didLoad)
  testStore.receive(.receiveData(.failure(.serverError))) {
    $0.error = .serverError
  }
  // before tap tryagain, change the env to success
  testStore.environment.loadData = { Effect(value: .success(1)) } // ⚠️ Change env on the fly

  // simulate tryAgain
  testStore.send(.didTapTryAgain) {
    $0.error = nil
  }
  testStore.receive(.receiveData(.success(1))) {
    $0.content = 1
  }
}

In that test, I change the return value of loadData via store.environment.loadData before tapping the try again button, so the return value after tapping the try again button will be changed.

I can use the similar approach when using environment via the Dependency property wrapper.

func testTryAgainAfterErrorLoadingPage() {
  let testStore = TestStore(
    initialState: MyState(),
    reducer: MyFeature()
  )

  testStore.dependencies.myEnvironment.loadData = {
    .failure(.serverError)
  }

  testStore.send(.didLoad)
  testStore.receive(.receiveData(.failure(.serverError))) {
    $0.error = .serverError
  }
  // before tap tryagain, change the env to success
  testStore.dependencies.myEnvironment.loadData = {
    .success(1)
  }

  // simulate tryAgain
  testStore.send(.didTapTryAgain) {
    $0.error = nil
  }
  testStore.receive(.receiveData(.success(1))) {
    $0.content = 1
  }
}

Using first approach, we can modify the response of loadData on the fly via testStore.dependencies.myEnvironment.loadData

But for the second approach, it's not as straight forward to change the response on the fly, as the reducer is value type and we can't know the type of the reducer inside the TestStore.

What I am thinking about how to change it on the fly is by using a flag to flip the response like this:

func testTryAgainAfterErrorLoadingPage() {
  var isSecondHit = false
  let env = MyEnvironment(
    loadData: {
      if !isSecondHit {
        isSecondHit = true
        return Effect(value: .failure(.serverError))
      } else {
        return Effect(value: .success(1))
      }
    }
    )
  let testStore = TestStore(
    initialState: MyState(),
    reducer: MyFeature(env: env)
  )

  testStore.send(.didLoad)
  testStore.receive(.receiveData(.failure(.serverError))) {
    $0.error = .serverError
  }
  // simulate tryAgain
  testStore.send(.didTapTryAgain) {
    $0.error = nil
  }
  testStore.receive(.receiveData(.success(1))) {
    $0.content = 1
  }
}

Is there easier way to change the response of the Environment via the init than this?

Thank you 🙏🏻

[mbrandonw]

Hi @jeffersonsetiawan, unfortunately it is not easy to swap out dependencies in the middle of a test if you are using the explicit, environment-style of dependencies. Is there a reason you can't use the new dependency system?

My personal recommendation is to try to get to the @Dependency style, but if there is a reason you can't yet, you could also consider a kind of Lazy reducer. It would be a class, hold onto an environment, and hold onto another reducer. That way it could pass the current environment to the inner reducer when it is executed, and you could change the environment midway in a test. And then you could use it like this:

let reducer = Lazy(
  environment: MyEnvironment.mockFailed,
  reducer: MyFeature.init(environment:)
}

func testTryAgainAfterErrorLoadingPage() {
  let testStore = TestStore(
    initialState: MyState(),
    reducer: reducer
  )

  // ...
  reducer.environment.loadData = { Effect(value: .success(1)) } 
  // ...
}

[mbrandonw]

Hi @jeffersonsetiawan, unfortunately it is not easy to swap out dependencies in the middle of a test if you are using the explicit, environment-style of dependencies. Is there a reason you can't use the new dependency system?

My personal recommendation is to try to get to the @Dependency style, but if there is a reason you can't yet, you could also consider a kind of Lazy reducer. It would be a class, hold onto an environment, and hold onto another reducer. That way it could pass the current environment to the inner reducer when it is executed, and you could change the environment midway in a test. And then you could use it like this:

let reducer = Lazy(
  environment: MyEnvironment.mockFailed,
  reducer: MyFeature.init(environment:)
}

func testTryAgainAfterErrorLoadingPage() {
  let testStore = TestStore(
    initialState: MyState(),
    reducer: reducer
  )

  // ...
  reducer.environment.loadData = { Effect(value: .success(1)) } 
  // ...
}

[jeffersonsetiawan]

Thanks for replying @mbrandonw .
There are some case that each page (ViewControllers) need to have new instance of the environment/dependency.
My finding is this case might be happen for example if the environment is a long living effect (that can emit value more than once), but it holds some data that change over time.

[dikasetiadi]

Hi @mbrandonw
i'm tried to implement based on your explanation:

internal final class OnTheFlyInjectionReducer<Base: ReducerProtocol, Environment>: ReducerProtocol {
    internal var environment: Environment
    private let create: (Environment) -> Base
    
    internal init(
        enviroment: Environment,
        reducer create: @escaping (Environment) -> Base
    ) {
        self.environment = enviroment
        self.create = create
    }
    
    @inlinable
    internal func reduce(into state: inout Base.State, action: Base.Action) -> Effect<Base.Action> {
        self.create(environment).reduce(into: &state, action: action)
    }
}

using above implementation, we can do swap out our environment in the middle of a test.
So basically we are call create func everytime the reduce func called, but is it okay to do recreate the reducer instance? i'm still not sure about this one.