Need some help in understanding how to test this f...

# coroutines

[sjthn]

Need some help in understanding how to test this function:

fun onCreate() {
    val user = profile.getUser()
    if (!user.contains("token")) {
        coroutineScope.launch(coroutineExceptionHandler) {
            launch(<http://Dispatchers.IO|Dispatchers.IO>) {
                try {
                    val token = network.fetchToken()
                    // ...
                } finally {
                    withContext(Dispatchers.Main) {
                        view.hideProgressBar()
                    }
                }
            }
        }
    } else {
        // ...
    }
}

I wrote a test function to verify if network.fetchToken() is called when condition is met. I wrapped it in runBlocking but test fails. Any ideas on how to test this?

[gildor]

What kind test are you writing?

[gildor]

It looks untestable for unit tests for me

[gildor]

Instead of working with side effects, instead you should return value from function and test it

[gildor]

If it’s some integration test just test side effects, do not test function itself

[gildor]

Also this doesn’t have sense for me

coroutineScope.launch(coroutineExceptionHandler) {
            launch(<http://Dispatchers.IO|Dispatchers.IO>) {

[gildor]

Just replace with

coroutineScope.launch(coroutineExceptionHandler  + <http://Dispatchers.IO|Dispatchers.IO>) {

[gildor]

and not sure why you use IO there, is fetchToken blocking?

[sjthn]

i am doing unit test. fetchToken is a network call

[gildor]

I understand that it’s network call, but how is it implemented?

[gildor]

I just trying to undertstand why do you need <http://Dispatchers.IO|Dispatchers.IO>

[sjthn]

fetchToken is a suspend function. that calls the api and returns the result synchronously

[sjthn]

in Android, n/w call can't happen on main thread. so need a IO thread

[gildor]

if it’s suspend function than it’s not syncronous, it is asyncronous by definition

[gildor]

Do you use retrofit 2.6 with suspend function support?

[sjthn]

yes

[gildor]

Than you don’t need <http://Dispatchers.IO|Dispatchers.IO>, Retrofit requests running on OkHttp dispatcher by default

[gildor]

so it’s completely fine to call it from Main thread, that is the whole point of dispatchers and coroutines, to be asyncrous and provide sequential-like way to write code

[sjthn]

okay thanks. didnt know that. i thought we anyway need to call it in a non-ui thread.

And now my test is working. But when I run all the tests some are failing.

[sjthn]

I am using Dispatchers.setMain() and resetMain() in my test class

[gildor]

i thought we anyway need to call it in a non-ui thread

See, suspend function is like a callback with some compile time magic, same way as with Retrofit callbacks you do not switch thread where to run it, you shouldn’t do this for suspend function if it’s not required

[gildor]

I run all the tests some are failing.

I don’t know what your tests are testing, so hard to say anything, try to investigate

[gildor]

If you just replace Dispatcher it may work for some cases, but not for cases when you do actual network call for example, which is asyncronous

[gildor]

I really recommend you to read official coroutine guide first

[gildor]

https://kotlinlang.org/docs/reference/coroutines/coroutines-guide.html

[sjthn]

I went through the guide. The testing part seems difficult. I'll go through it once again. Thanks for the help.

[gildor]

The testing part seems difficult

Because your function is written in a way which is very hard to test, it would be the same with any async API if you write your code this way. Essentially when you call this function you just run background job and have no way to await or know result, you just have some side effect but to check it you should wait for this job, which is not easy in this case.
Of course you can replace of dispatchers for tests with Unconfined and it will work, but pretty fragile (if any of functions switches context your test will be broken)

[gildor]

I really don’t see how it would be different with any other async api: callbacks, rxjava, retrofit.Call etc

[sjthn]

This is my test:

@Test
fun `make api call if token is not present`() {
    `when`(profile.getUser()).thenReturn("")
    runBlocking {
        presenter.onCreate()
        verify(network).fetchToken()
    }
}

[gildor]

exactly

[gildor]

onCreate is just do some side effect

[gildor]

To test it this way you should replace all dispatchers with Unconfined, because there is no other simpole way to wait for it

[gildor]

Instead, you can extract this to some suspend function, do request, receive result and then validate that token was requested (or even better returned together with User)

[gildor]

again, I don’t have your original code, hard to recommend particular solution

[gildor]

It’s common pattern with any asyncronous API

[gildor]

It’s not the only way of course, you also can observe some state to know when presenter init is finished, or something like that

[sjthn]

Instead, you can extract this to some suspend function, do request, receive result and then validate that token was requested (or even better returned together with User)

But I am doing that only IIUIC. Extracted the n/w request to a suspend function that returns the token. So checking whether that token was requested i.e, the function was called or not

[gildor]

yes, I just want to say that testing functions that do something asyncronous and return nothing is hard

[gildor]

you need sime another approach

[gildor]

Reaplace with Unconfined dispatcher kinda work in most cases, but it also not how it works on real app

[gildor]

So because of this I recommend to use some approach that will allow you to test it properly

[gildor]

without context I cannot propose some particular solution

[sjthn]

cool. will figure out. thanks you so much

[rook]

Just wanted to point out, if the side effects result in a call to an object with an interface, you can check that the function was called with a mocked version of the interface (like your view, for example)

[sjthn]

@rook yes that's what i am doing. That works fine if it's not in coroutine.