TestStore and implicitly returned actions

[ferologics]

Is it by design that action returned concatenated effects in TestStore are not received?

I.e. in following reducer:

enum Action { case onAppear, testA, testB }
testReducer = { ...
  case .onAppear: return .concatenate(
    .init(value: testA), .init(value: .testB)
  )
}

The test case fails:

testExample() {
  ...
  testStore.send(.onAppear)
  testStore.receive(.testB) // ❌ will not be received
  // Expected to receive an action, but received none.
}

This is suuuuuper confusing to me as a newb to TCA testing. I would literally put my hand into the fire that the .onAppear returned .testB action should be received. Do I have to advance some scheduler, or somehow wait for the second action to be received?

[mbrandonw]

Can you provide a fully compiling example to show the behavior you are seeing versus the behavior you expect?

FWIW this test passes and it is what I would expect:

func testConcatenate() {
  enum Action { case onAppear, testA, testB }

  let store = TestStore(
    initialState: 0,
    reducer: Reducer<Int, Action, Void> { state, action, _ in
      switch action {
      case .onAppear:
        return .concatenate(
          .init(value: .testA), 
          .init(value: .testB)
      )
      case .testA:
        return .none
      case .testB:
        return .none
      }
    },
    environment: ()
  )

  store.send(.onAppear) ✅
  store.receive(.testA) ✅
  store.receive(.testB) ✅
}

[ferologics]

Here's the the project reproducing a concrete failing test example. It's using the ComposableCoreLocation.

[mbrandonw]

I think you want .merge here, not .concatenate.

With concentration of publishers the .init(value: .test) effect is not started until the first effect completes, but the effect env.locationManager.create is a long living one and will not complete until you cancel it. That is why .init(value: .test) never seems to feed back into the store.

[ferologics]

That's kinda what I did to make the test pass, but I am not sure if the live LocationManager will be created correctly and will return the right value from env.locationManager.authorizationStatus() if I return the effect as .merge (which will return the two actions at the same time). I'd expect env.locationManager.create(id: LocationManagerId()) to run first, and then do something with it (which is why I opted in for .concatenate in the first place).

[mbrandonw]

The .create endpoint on the location manager is a long living effect because it is what sends back all of the delegate methods from the location manager delegate:

https://github.com/pointfreeco/composable-core-location/blob/9e9f1809ba52cc5f1b157c726b87e4e7ce4dbefd/Sources/ComposableCoreLocation/Interface.swift#L178-L239

So you will never want to concatenate something after it. I suppose you could create an alternate API of this dependency that separates a .create endpoint from a .delegate endpoint, but I don't see a benefit to doing that right now.

Also, the .merge in this cause is fine because .create executes synchronously to create the location manager, and so it completely fine to reference the manager immediately after .create:

return .merge(
  env.locationManager.create(...),
  env.locationManager.requestLocation(...)
)

One last thing, the endpoint env.locationManager.authorizationStatus() is just calling a static method on CLLocationManager, and so you can call it without ever creating a location manager. That's why this endpoint doesn't take an id.

[ferologics]

Thanks for the clarification, this makes absolute sense now! Case closed 👍