测试 Kotlin 控制台时注入哪个协程调度程序

Question

I have a back-end springboot Kotlin app that has some simple coroutine code for parallel IO operations. It looks something like this

@Service
class AccountService(
    private val client: ApiClient
    private val coroutineDispatcher: CoroutineDispatcher
) {

  fun getAccount(): AccountDTO {

    return runBlocking(coroutineDispatcher) {
      val foo = async {
        client.getFoo() //some long operation
      }

      val bar = async {
        client.getBar() //some other operation
      }

      AccountDTO(foo.await(), bar.await())
    }
  }
}

Now in production I can inject let's say a Dispatchers.IO dispatcher and everything works fine. However when testing I don't want multithreading. I want to inject Dispatcher.Main but it's meant for android apps. Alternatively I'd like to inject nothing and let the scope inherit from the parent and run on the main thread, the way runBlocking{} works without any arguments. But I can't figure out how to do that. Should I be using Dispatchers.Unconfined ? From what I understand it will stay on the main thread unless I spin up another thread myself explicitly.

What's the standard practice here?

Answer 1

Alternatively I'd like to inject nothing and let the scope inherit from the parent and run on the main thread, the way runBlocking{} works without any arguments. But I can't figure out how to do that

If you have control over getAccount() here, you should make this one suspend and avoid runBlocking at this level. If you're just introducing coroutines in the project, it's of course fine like this as a first step, but I would encourage you to keep going up the call stack soon. This way you'll benefit from context inheritance and avoid blocking threads from other coroutines if they decide to call your service.

Now, you could use kotlinx-coroutines-test for your tests, they provide test dispatchers that you can use, which even allow you to control virtual time and test timeouts etc. Note, however, that due to the virtual time, you cannot use this kind of dispatcher for code that calls an actual system that's not part of virtual time (like some external service, or just a piece of code using a hardcoded non-test dispatcher).