Missing state transitions

[fabfelici]

Let's imagine we have:

protocol Service {
  func data() -> AnyPublisher<Void, Never>
}

enum State {
  case idle, loading, loaded
}

enum Action {
  case load, loaded
}

let reducer = Reducer<State, Action, Service> { state, action, env in

  switch state {
  case .idle:
    switch action {
    case .load:
      state = .loading
      return env.data()
        .map { .loaded }
        .eraseToEffect()
    default:
      return .none
    }

  case .loading:
    switch action {
    case .loaded:
      state = .loaded
      return .none
    default:
      return .none
    }

  case .loaded:
    return .none
  }
}

These entities can be used to represent a simple state machine that:

• starts from idle state
• waits for a load action and transitions to loading state while returning effect to download data from Service
• receives loaded action and transitions to loaded state

Now let's say that we want to test this scenario and we use a mocked Service that returns immediately:

struct MockService: Service {
  func data() -> AnyPublisher<Void, Never> {
    return Just(()).eraseToAnyPublisher()
  }
}

By using this test:

let store = Store(
  initialState: .idle,
  reducer: reducer,
  environment: MockService()
)

var emissions: [State] = []
let viewStore = ViewStore(store)
viewStore.publisher
  .sink { emissions.append($0) }
  .store(in: &self.cancellables)

viewStore.send(.load)

XCTAssertNoDifference(emissions, [.idle, .loading, .loaded])

we can see that it is failing because emissions = [.idle, .loaded] and so .loading transition is missing.

Now, this is not an issue with the real Service implementation because the real service doesn't return immediately and Store emits .loading state.
For tests though, I would have to introduce Scheduler in the mocked service to "fake" timings of side effects.
TCA comes with a test: testCoalesceSynchronousActions that basically is against what I'm expressing here and I would like to understand the reasons behind it.
IMO we should always emit a new State if an action mutates it and by introducing this change to Store:

func send(_ action: Action, originatingFrom originatingAction: Action? = nil) {
  self.threadCheck(status: .send(action, originatingAction: originatingAction))

  self.bufferedActions.append(action)
  guard !self.isSending else { return }

  self.isSending = true
  var currentState = self.state.value
  defer {
    self.isSending = false
    self.state.value = currentState
  }

  while !self.bufferedActions.isEmpty {
    let action = self.bufferedActions.removeFirst()
    let effect = self.reducer(&currentState, action)

    var didComplete = false
    let uuid = UUID()
    let effectCancellable = effect.sink(
      receiveCompletion: { [weak self] _ in
        self?.threadCheck(status: .effectCompletion(action))
        didComplete = true
        self?.effectCancellables[uuid] = nil
      },
      receiveValue: { [weak self] effectAction in
        self?.send(effectAction, originatingFrom: action)
      }
    )

    if !didComplete {
      self.effectCancellables[uuid] = effectCancellable
    } else if !bufferedActions.isEmpty {
      self.state.value = currentState
    }
  }
}

my test passes but testCoalesceSynchronousActions fails.
So, what do you guys think? Can anyone explain why we have testCoalesceSynchronousActions?
Thank you!

[lukeredpath]

This behaviour is to reduce the number of unnecessary emissions from the publisher.

#619

If all state mutations occur synchronously there is no need for subscribers to know about intermediate states. Only the end state matters.

In your test, if you have an effect that returns a result immediately it makes complete sense that the state transitions directly from idle to loaded…there was no “loading” state because the load was immediate. To that end the test is correct.

If you want to test the flow from idle to loading to loaded, then it would be more realistic to have an effect that allows you to control when it outputs a value using e.g. a PassthroughSubject, erased to an effect and testing the flow that way.

[fabfelici]

@lukeredpath Thanks for answering and for the link to the PR (I missed it)!

This behaviour is to reduce the number of unnecessary emissions from the publisher.

I get it but, should Store be responsible of this? Can't subscriber use throttle (or other filtering operators) on the state stream for example?

If all state mutations occur synchronously there is no need for subscribers to know about intermediate states. Only the end state matters.

This makes testing a bit more complicated because, as you are suggesting, PassthroughSubject would be needed and test will have subject.send calls to control effect emissions and be sure that all state transitions are happening correctly. IMO happy paths written with Just for example should also work in tests.

[lukeredpath]

But testing with an effect that completes immediately is not the same as testing with an effect that does not, at least not when you care about the progress of that effect as you do here, so you’re testing two different behaviours. IMO your test should accurately reflect the real world behaviour. In the real world your async effect would never just complete.

IMO a test dependency that you can control deterministically with a subject does not make testing more complicated, I’d argue it makes the behaviour under test much clearer.