Sometime getting main-thread checker warning on Unit-test

[khairilushan]

Hi everyone,

So I have this code in my reducer

case let .searchTextFieldChanged(keyword):
	struct SearchID: Hashable {}

	state....

	guard !keyword.isEmpty else {
		state....
		return .cancel(id: SearchID())
	}

	return Effect.task {
		do {
			return Action.searchResponse(.success(try await environment.search(keyword)))
		} catch {
			return Action.searchResponse(.failure(error as! AppError))
		}
	}
	.debounce(id: SearchID(), for: 0.3, scheduler: environment.mainQueue)
	.receive(on: environment.mainQueue)
	.eraseToEffect()

And the environment looks like this

struct SearchEnvironment {
	var search: (String) async throws -> [Item]
	var mainQueue: AnySchedulerOf<DispatchQueue>
}

I tried to write a test for the reducer, and it look like this

func testSearchShouldFail() {

	let store = TestStore(
		initialState: SearchState(),
		reducer: searchReducer,
		environment: SearchEnvironment(
			search: { _ in throw AppError.unauthorized },
			mainQueue: .immediate
		)
	)

	store.send(.searchTextFieldChanged("iOS")) {
		$0....
	}
	store.receive(.searchResponse(.failure(.unauthorized))) {
		$0....
	}
	store.send(.searchTextFieldChanged("")) {
		$0....
	}
}

And the problem is when I try to run the test, sometime I'll get this warning and then it will fail on the store.receive line. And sometime it will pass smoothly.

Warning:

A store created on the main thread was interacted with on a non-main thread:

  Thread: <NSThread: 0x600000375140>{number = 5, name = (null)}

An effect returned from "TestAction" emitted the action "TestAction" on a non-main thread. Make sure to use ".receive(on:)" on any effects that execute on background threads to receive their output on the main thread, or create this store via "Store.unchecked" to disable the main thread checker.

The "Store" class is not thread-safe, and so all interactions with an instance of "Store" (including all of its scopes and derived view stores) must be done on the main thread.
---

But when running on simulator, all the actions landed on main-thread just fine. So, anyone know which part did I done wrong in my implementation ?

[mbrandonw]

Hi @khairilushan,

this is happening because the .immediate scheduler simply performs its work right away, on whatever thread it happens to be on. So, in tests, when you run the reducer and cause the effect to await it switches to a new thread, and then delivers its output to the store on a background thread.

This doesn't happen when running the app because there you are using a regular DispatchQueue.main.

In order to get this to work you will need to use a live DispatchQueue.main in your tests, which means you will need to perform await Task.sleep in the test in order to wait for schedulers to do their work. This also means you will need to make your test async, which then means you will need to make your test case/class @MainActor.

Note that we do not really recommend using .task directly in the reducer, and it's because of this reason. We have a note of this in the documentation:

swift-composable-architecture/Sources/ComposableArchitecture/Effects/Concurrency.swift

Lines 23 to 30 in fe97ad6

	/// Note that due to the lack of tools to control the execution of asynchronous work in Swift,
	/// it is not recommended to use this function in reducers directly. Doing so will introduce
	/// thread hops into your effects that will make testing difficult. You will be responsible
	/// for adding explicit expectations to wait for small amounts of time so that effects can
	/// deliver their output.
	///
	/// Instead, this function is most helpful for calling `async`/`await` functions from the live
	/// implementation of dependencies, such as `URLSession.data`, `MKLocalSearch.start` and more.

We are working on some tools in the short term that will make it possible to use .task as you are, and in the long term a more full integration with all of Swift's concurrency tools will make all of this really nice. 🙂

[khairilushan]

Thanks a lot for the thorough answer @mbrandonw .