When exhaustivity is off receive now waits for the expected action rather than the first action

[alex-reilly-pronto]

In the doc comments for the receive functions, the nanoseconds/duration timeout params are described as The amount of time to wait for the expected action. This is true when exhaustivity is on because receiveAction(actionPredicate:timeout:file:line) waits for any action to be received. However, when exhaustivity is off, users are allowed to skip receiving actions in their tests, so waiting until any action is received is not the same as waiting for the expected action to be received.

This PR resolves that by having receiveAction(actionPredicate:timeout:file:line) wait until actionPredicate is met by one of the received actions when exhaustivity is off. The existing behavior stays the same when exhaustivity is on.

[stephencelis]

@alex-reilly-pronto Can you provide a description of what this PR intends to do? Also, if you found a bug, can you include some tests that would have failed before the changes you made?

[mbrandonw]

Hi @alex-reilly-pronto, thanks for the PR! I think you definitely have found a bug/oversight with non-exhaustive test stores. However, as @stephencelis mentioned, can you please update the PR description to describe exactly what the problem is and how you are fixing. This is important for us to have for our records.

Also it would be nice to get some test coverage. Here is something you can use to get started:

func testReceiveWithTimeout() async {
  struct Feature: ReducerProtocol {
    struct State: Equatable {}
    enum Action: Equatable { case tap, response1, response2 }
    func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
      switch action {

      case .tap:
        return .run { send in
          try await Task.sleep(nanoseconds: 1_000_000_000)
          await send(.response1)
          try await Task.sleep(nanoseconds: 1_000_000_000)
          await send(.response2)
        }
      case .response1, .response2:
        return .none
      }
    }
  }

  let store = TestStore(initialState: Feature.State(), reducer: Feature())
  store.exhaustivity = .off

  await store.send(.tap)
  await store.receive(.response2, timeout: 3_000_000_000)
}

[alex-reilly-pronto]

@stephencelis @mbrandonw Wrote up an explanation for the PR and threw in some tests. Thanks for the example! Let me know if anything is unclear

[mbrandonw]

Thanks for the PR @alex-reilly-pronto! This looks good to us and we will merge soon.

[alex-reilly-pronto]

Awesome! Happy to hear it. Is that CI failure expected or did I break something?

[alex-reilly-pronto]

Oh nevermind this is one of mine:

Test Case '-[ComposableArchitectureTests.TestStoreNonExhaustiveTests testReceiveNonExhuastiveWithTimeout]' started.
/Users/runner/work/swift-composable-architecture/swift-composable-architecture/Tests/ComposableArchitectureTests/TestStoreNonExhaustiveTests.swift:743: error: -[ComposableArchitectureTests.TestStoreNonExhaustiveTests testReceiveNonExhuastiveWithTimeout] : Expected to receive a matching action, but received none after 0.003 seconds.

There are effects in-flight. If the effect that delivers this action uses a clock/scheduler (via "receive(on:)", "delay", "debounce", etc.), make sure that you wait enough time for it to perform the effect. If you are using a test clock/scheduler, advance it so that the effects may complete, or consider using an immediate clock/scheduler to immediately perform the effect instead.

If you are not yet using a clock/scheduler, or can not use a clock/scheduler, try increasing the duration of this assertion's "timeout".
Test Case '-[ComposableArchitectureTests.TestStoreNonExhaustiveTests testReceiveNonExhuastiveWithTimeout]' failed (0.010 seconds).

Maybe it needs a longer timeout?

[mbrandonw]

I just bumped the timeouts. They are a bit flakey, but we do have some tools coming soon to improve the situation.

[alex-reilly-pronto]

Ope we had the same idea. Feel free to roll mine back if you don't want all of them bumped.