How To Unit Test LiveData and Lifecycle Components
Since the announcement in last Google I/O on New Architecture Components they become a hot topic in the Android Developer community, among other components, LiveData has the most impact on the way that Android developers think since it introduces the reactive pattern. Developers that weren’t fans of reactive programming have started to think about this approach since this is the way that Google recommends.
Additional great component is Lifecycle, the lifecycle become a first-class citizen in Android, now we might have Lifecycle owner that manages the lifecycle and we can observe changes in the lifecycle and react upon them, so also the lifecycle contribute to the thinking about the reactive pattern.
The combination of both components has huge bonuses, the death of WeakReference of the View which a very common pattern to avoid context leaks. When the View consumes its data that it needs to render from LiveData we invert the imports direction that we used to do, before using this pattern the Presenter was aware at least to the interface of the View but now it doesn’t care anymore about who consumes the data that it produces, all it should do is to write to the LiveData and anyone that wants this data can consume the data, so it totally decouples the View from the Presenter.
But We Have RxJava
Developers that already use RxJava might read the above and think that LiveData is not for them but lifecycle problem is also problem in the RxJava world and there are a lot of good libraries that try to tackle this problem and some them even admit that it’s a hard problem, so also RxJava developers can take the advantage of LiveData which solve the lifecycle problem out of the box and connect their streams to LiveData (LiveData observation done in the UI thread so it save you to do it manually as well), or at least use the Lifecycle awareness to overcome that problem.
How Does Live Data Work?
LiveData holds a value, this value may change by calling to one of the following methods setValue or postValue, whenever the value changed the LiveData might notify its observers about the change. When calling SetValue the value is immediately change but you must be in the UI thread otherwise you should use postValue which write the new value asynchronously. I’m prefer alway to call postValue in order to avoid the checks whether I’m calling it from the UI thread or not.
How To JUnit postValue
Calling to postValue might be a bit tricky in JUnit since everything is running in the Main thread calling to postValue will probably will write the value only after the test will end, to overcome it you can add InstantTaskExecutorRule (you need to add Gradle dependency `android.arch.core:core-testing`)to your test, this rule will make sure that the writing of the value will synchronous instead of asynchronous.
How To Observe LiveData In JUnit Test
In Order to observe LiveData changes you should provide instance of Lifecycle, the LiveData need a way to retrieve the current state of the lifecycle and in some states the LiveData will notify the observers on the change in the value . In JUnit test we can use LifecycleRegistry as a Lifecycle, and change the state by calling to the method handleLifecycleEvent with the right event, so in test, we set the state to be RESUMED so our observers will be called
If you didn’t consider to use LiveData or Lifecycle until now I’m hoping that this post will inspire you to think about it, those components save you a lot of headaches and you can test them with JUnit easily.
