How use and test Kotlin Coroutines with MockK library
In these article we will understand how implement the new Kotlin coroutines and how test them with MockK library. I use these code in an Android project, but the principles are generic for all Kotlin project.
Dispatcher and CoroutineScope
If you worked in past with RXJava you should understand the concept of Scheduler, a dispatcher is something of similar and the CoroutineScope works in the same way to garante a scoping of function.
Defines a scope for new Coroutines. Every Coroutine builder is an extension on CoroutineScope and inherits its CoroutineContext to automatically propagate both context elements and cancellation.
A scope controls the lifetime of Coroutines through its job. When you cancel the job of a scope, it cancels all Coroutines started in that scope. The Dispatchers.IO is like Schedulers.IO of RXJava, it indicates the thread pool of a function.
Create a Coroutine
In these sample we use coroutines to fetch user’s github repositories to do that we have created a Repository implementation with a Retrofit request.
In this snippet of code there is an important thing to notice, the suspend modifier of the method signature, this modifier will mark the function as a coroutine method, it will be use only inside a lamba runBlock expression.
Now we put the implementation inside an UseCase as Uncle Bob wants in the Clean Architecture pattern.
Finally we can see the Android ViewModel where we use the GetRepositoriesUseCase interactor. The fetchRepositories() method downloads the repositories list via the UseCase inside a ioScope , this scope allows the UseCase to work inside a separated background thread, instead the response is manage inside the uiScope to publish the response on the Android UI Thread.
Test a Coroutine ViewModel
Now the main focus of the article: we have a ViewModel that uses coroutines, our goal is to verify that after method invoke we find the request result inside the respositoriesLiveData. To do that we need only to mock the UseCase result, below you can see the unit test.
From these examples we need to notice two things: first of all to mock the response of a suspend function you must use coEvery{} method and not the classic every{} . The second important thing is to use the dispatcher Dispatcher.Unconfirmed to define che CoroutineScope inside the ViewModel, this is important to prevent asynchrony problems between the coroutines running and the Junit asserts.
If you want to test the GetRepositoriesUseCase principles are same but you must put the body inside a runBlock{}, it’s mandatory to test a suspend function, you can see an example below:
Thanks for reading
I hope I helped you with this article, if you have other questions, please let me know! If you have liked this article don’t forget to 👏it. Thanks!
The full source code of the project is below:
