Trying to test a `okhttp3.Authenticator` which unf...
# coroutines
s
Trying to test a
okhttp3.Authenticator
which unfortunately isn’t suspending and I am in there using
runBlocking
to bridge this gap. My problem is as such: In the body of that authenticator, everything is wrapped with a
runBlocking
but that one in turn calls a suspending function from another service. That function in turn, calls other suspending functions which at some point are using the CoroutineContext given from TestScope.backgroundScope (Or even TestScope itself). This means that then runBlocking is waiting for that to run, and the test is hanging waiting for
runBlocking
to finish at the same time, not giving me an opportunity to call
runCurrent()
or something like that to make the coroutine actually run. I guess this brings me to the question, should I be going with an UncofinedTestDispatcher here? I am kinda scared of using that usually since I don’t have good control of what’s going on, but I don’t know if that’s the more “appropriate” way to run tests with
runTest {}
. I usually default to not using UnconfinedTestDispatcher unless really needed, is this a bad habit?
f
You're trying to test code that is effectively multithreaded (because blocking) using a single thread. No matter if you use a standard test dispatcher or unconfined, you're test will always be fake in any case, not reflecting what is going on in production. I would even probably switch to dispatchers.default for this test. You can use freely an unconfined test dispatcher if you want, it doesn't make your test fake than the standard one. (In production you may get the unconfined or standard behavior depending on the thread scheduling, right?)