kotlin-coroutines-retrofit | Kotlin Coroutines await extension for Retrofit Call | Android library

You found solution, but maybe for other people, especially beginners, it might be helpful to explain why you were getting errors in the first place and why runBlocking helps. The issue is, that when running unit tests, the expectation is, that these tests are synchronous, that is, if any code is executed on some separate thread some time later, the test runner will never know about that, because for the test runner the test is finished when it's method call on the test runner's thread is finished.

Therefore it is impossible to test code not running on the main thread. In fact, it is even a bad practice trying to do that. Since there is no guarantee of when the code running on another thread will finish (if ever), we don't know what state the main thread will be in at the time (the main thread might not even exist anymore, as is the case with unit test runner).

Even if it were somehow possible to test code executed in other threads, every test run would inevitably be different (as a consequence of the above paragraph) and tests might produce different results on every run. That goes directly against the ideology of tests being reliable and yielding the same results on every single run.

Therefore when testing, all tested code needs to run on the main thread and one should make sure to never try call any asynchronous code in tests.

The runBlocking coroutine, unsurprisingly runs the code within it in blocking manner, on the thread it is launched from (as opposed to launch, that will cause the code to be run asynchronously).

There's one caveat to all this, that coroutines are not threads, but if you replace the word thread in the above text for asynchronous coroutine, the text will not lose any of its meaning. What I said is applicable for both when you're using traditional threads and also when you're using coroutines.