Testing parallel effects

[m-makhovyk]

Hey guys! In my feature I have two actions that run side effects. And I'm trying to test that result of one specific effect does not override result of another. Here is a sample:

import XCTest
import ComposableArchitecture
import ConcurrencyExtras

final class TestTCA: XCTestCase {

  @Reducer
  struct Feature {
    @ObservableState
    struct State: Equatable {
      var value = 0
    }
    enum Action {
      case setValue(value: Int, delay: Int)
      case valueSet(value: Int)
    }

    var body: some Reducer<State, Action> {
      Reduce { state, action in
        switch action {
        case .setValue(let value, let delay):
          return .run { send in
            try await Task.sleep(for: .seconds(delay), clock: .immediate)
            await send(.valueSet(value: value))
          }
        case .valueSet(let value):
          state.value = value
          return .none
        }
      }
    }
  }
    
  @MainActor
  func testTestStoreEffectsSerially() async throws {
    let store = TestStoreOf<Feature>(initialState: Feature.State(), reducer: { Feature() })
    store.exhaustivity = .off
    
    await store.send(.setValue(value: 5, delay: 0))
    await store.receive(\.valueSet, timeout: 1)
  
    Task {
      await store.send(.setValue(value: 10, delay: 1))
    }
    Task {
      await store.send(.setValue(value: 20, delay: 0))
    }
    
    // failed
    //await store.receive(\.valueSet, 20, timeout: 5)
    //await store.receive(\.valueSet, 10, timeout: 5)
    
    try await Task.sleep(for: .seconds(2))
  
    //XCTAssertEqual(store.state.value, 10) // should be 10
  }

  // working without TestStore
  @MainActor
  func testSendParallel() async throws {
    let store = StoreOf<Feature>(initialState: Feature.State(), reducer: { Feature() })
    
    store.send(.setValue(value: 5, delay: 0))
    try await Task.sleep(for: .seconds(1))
    XCTAssertEqual(store.state.value, 5)

    async let t1 : () = await store.send(.setValue(value: 10, delay: 1)).finish()
    async let t2 : () = await store.send(.setValue(value: 20, delay: 0)).finish()
    
    await t1
    await t2
        
    XCTAssertEqual(store.state.value, 10)
  }
}

TestStore does not seem to respect provided delay.
Disclaimer: cancelling previous effect will work with this sample, but production code is a bit more complex, and cancelling is not a solution there.

[mbrandonw]

Hi @m-makhovyk, it is not necessary to spin up an unstructured task to send actions "in parallel":

// ❌ Not recommended
Task {
  await store.send(.setValue(value: 10, delay: 1))
}
Task {
  await store.send(.setValue(value: 20, delay: 0))
}

The await in TestStore's send doesn't mean "await until action and effects complete". It just means "await until action is processed and effects start."

This means you can typically just do this:

await store.send(.setValue(value: 10, delay: 1))
await store.send(.setValue(value: 20, delay: 0))
await store.receive(\.valueSet, 20, timeout: 5)
await store.receive(\.valueSet, 10, timeout: 5)

However, another problem with your code is that you have hardcoded the immediate clock in your reducer:

try await Task.sleep(for: .seconds(delay), clock: .immediate)

An immediate clock does not actually suspend for any time, and so the delays you are passing in are completely ignored. This means if you are going to use an immediate clock, then the test would actually have to be written with the receives in the opposite order:

await store.send(.setValue(value: 10, delay: 1))
await store.send(.setValue(value: 20, delay: 0))
await store.receive(\.valueSet, 10, timeout: 5)
await store.receive(\.valueSet, 20, timeout: 5)

…even though that seems counterintuitive. A TestClock would be more appropriate to use here, because that would allow you to write the test like this:

await store.send(.setValue(value: 10, delay: 1))
await store.send(.setValue(value: 20, delay: 0))

await clock.advanced(by: .seconds(1))

await store.receive(\.valueSet, 20)
await store.receive(\.valueSet, 10)

Also, we recommend against providing a timeout. That argument should rarely be used, and instead your tests should ideally run and pass without any explicit task sleeping.

[m-makhovyk]

Hey @mbrandonw, thanks a lot for your response! It works 👍 For some reason I thought using TestClock requires me to use some clock in production code 🤦