Is anyone by chance aware of any threading related...
# ktor
j
Is anyone by chance aware of any threading related changes that were made in
MockEngine
in 1.5.1.....we're updating a client here from a 1.4.x version and have isolated issue we're seeing to update from 1.5.0 to 1.5.1.....we have unit tests that are using
runBlockingTest
and getting
IllegalStateException: This job has not completed yet
after that update....digging deeper to try and narrow in on what's changed but just in case anyone encountered this before....
Alternatively, are there any particular recommended best practices for setting up ktor related unit tests like this (that perhaps we weren't previously following)?
j
if you change runBlockingTest to runBlocking, it works?
j
So, that seems to affect things all right but other part of test fails then.....haven't had chance yet to dig in to that
I went through changelog for 1.5.1 but nothing jumped out
a
You can find an explanation here https://youtrack.jetbrains.com/issue/KTOR-2629
j
so, we can't use
runBlockingTest
for unit tests that use
MockEngine
?
a
I did encounter the same issue and didn't find a way to solve it. @e5l is there a way to use
runBlockingTest
?
j
perhaps pattern like following could be used to allow test to inject/replace dispatcher used? https://developer.android.com/kotlin/coroutines/coroutines-best-practices#inject-dispatchers
e
Hey @John O'Reilly. The problem is caused by context change in MockEngine. Most likely testing library you’re using is not assuming that there are no suspension points in test. It should be some
await
method there. Could you provide the whole code snippet to figure it out?
j
Hi @e5l, I'm not using any other testing library....just standard unit test with
runBlockingTest
and then testing one of our classes that in turn is using another class that uses
MockEngine
based
HttpClient
. Do you know of any examples/samples etc that are able to use
runBlockingTest
that I can maybe compare to?
e
Could you check if the code is working with a regular
runBlocking
?
j
Partly, yes....but running in to other issues then which I'm still trying to get to bottom of
a
The one problem is that you have to wait for all delays.
j
fwiw we're injecting
TestCoroutineDispatcher()
when constructing the class under test
e
Please note:
Copy code
When switched to lazy execution using pauseDispatcher any coroutines started via launch or async will not execute until a call to DelayController.runCurrent or the virtual clock-time has been advanced via one of the methods on DelayController.
j
we are using those in some other tests....let me see if/how they can be applied here too
Just to clarify though....we're not using
pauseDispatcher
in these particular tests right now