Ehy y'all! I have a problem with testing with the new Coroutines. The problem is that I have a very long sync operation and I want to test the

runBlocking

behaviour happens even with a possible delay. In the following gist (https://gist.github.com/tiwiz/b85c72fb77148e6cc12aa378b762e94b) there is the code (the

delay

is only to test if the test waits or not). So far, we couldn't have it to wait, so we must be doing something wrong... does anyone have a clue about it?

Cann't you make

selectById

suspend? It would be much simpler then.

This code has really bad testability by default because you hide launch in selectById

That is the problem... unfortunately. the dao call is synchronous, so I have to move it off the main thread in some ways

you can use

withContext

just use

withContext(IO) {}

instead

suspend fun selectById(id: Int) = withContext(Dispatchers.IO) { delay(5000) dao.syncOperationWith(id) }

Let me try, thanks!

it’s just really bad practice in general (not only in coroutines) to run some parallel code as side effect without any handlers to join/await/cancel

the cancel is handled in the

onCleared

method, so that it can be canceled based on Android's lifecycle... is that wrong?

Yes, and one of the main reason it is bad practice is the poor testability.

How should I handle it, so that it is better?

use suspend functions everywhere when it’s possible

OK, in this case using

IO + job

is wrong, then?

It’s not wrong in general, but not sure that this is correct approach in your case

I see your point, thanks for the explanation!

I agree with the

suspend

method approach but here the job must be saved in the ViewModel

this is fine in some cases, but you pay with problems with testing, it’s general problem not really related to coroutines

so the ViewModel can be seen as the top level object

As alternative solution to test this code you can pass custom dispatcher with Unconfined context

on rx this can be done using a

TrampolineScheduler

to wait the end of the computation, is there something similar on the coroutines?

You can use Unconfined instead in coroutines, which is like default scheduler in Rx

yes, but in that example it works only without the delay at the beginning of the method

the Unconfined context works only if there aren’t any nested async/launch call

it’s not true anymore, coroutine builders now use coroutineScope context by default

I'll try this solution out as well, thanks!

btw I see your comment that you have StackOverflowError, probably you have this issue (fixed in develop): https://github.com/Kotlin/kotlinx.coroutines/issues/692

Yup, it looks like something like that