Testing of the MVI/MVVM architecture built with flows made easy

As it is common now, the correct architecture should contain decoupled layers. Inter-layer communication between them is done by streams, or in our case, flows, in Android. To make our solutions foolproof, we should create tests around every component, and the ViewModel is no exception. The more channels the ViewModel contains, the more challenging is to assert its complexity of it. The states should be emitted in a controlled way rather than in a chaotic.

Photo by Brett Jordan on Unsplash

Set up

Everything will be done without instrumentation tests, so the phone does not need to be connected.

These are the required Android dependencies needed at the app’s build.gradle for testing:

Sample ViewModel

The article will follow a simple ViewModel with one StateFlow (feel free to use the flow or any other channel), which carries all the information for any view. The ViewModel intakes one interface for mocking the repository, which does some work for a long time in the actual application.

Since, the plan is to create unit tests – the tests do not care about specific implementation under repository, beacuse it will be mocked. The unit tests will test logic of ViewModel, not repository. This will prevent failing of the testcases for ViewModel, eventhough the tests for the repository might be failing. The tests will point you to the current issues.

The app takes an event, which launches the job and goes through a series of events. Sealed states are used to utilise the exhaustive listing of the states. All it does is minimise place for errors and possible logic issues.

If the state carries some data, use the data class , because the test can seamlessly compare the received state and expected state. The Android Studio will even generate comparison function for the data class, if it is needed. The simple class would result in an error every time as the hashcodes of the two different instances would not be the same.

Testing the ViewModel

Initial test case

With the ViewModel prepared, let’s create the first unit test about checking our default state in the StateFlow. The ViewModel waits for the event, so the expected state is Waiting. Here is the introductory code:

It is a lot going on there, so let’s explain it step by step:

1. Firstly, the required dependencies by our ViewModel need to be defined. We have an interface HeavyComputationTemplatewhich abstracts the logic for the ViewModel. Since it is an interface, the dependency can be mocked with annotation @Mock and mock() at the beginning without any specific implementation or stubs.
2. After initialization of the dependencies, the ViewModel can be instantiated with mock. (sut — system under test — the target of tests)
3. @Before defines code running every time before the test. We want a new instance of the ViewModel.
4. Mocked classes are stubbed with a great variety of dictated behaviours during the running of the test to achieve the required behaviour. To clean them, the reset the statement is used to clean the mock of all stubs.
5. Assertion of the ViewModel’s StateFlow that it contains the expected state.

Try to run it as a test, and if a green check appears, the following tests can be done.

I like to create first test for default set up of the class. It can act as proof of good initialisation of the class / it simplifies initial debugging of dependencies.

Testing one StateFlow

Let’s create the test for launching the computation task with the expected result in the form of a string, which the app should receive in the form of a state.

1. runTest executes the test in its coroutine, which most times does the same job as runBlocking . Without any changes, it skips delay within the coroutine. This results in the immediate execution of tests without waiting for the result. The test is run on a single thread, so any child coroutine is always run on the same thread if it is not defined in another way.
2. .stub prepares the mock to expect the call on itself. If the mocked input does not correspond to the input during the code execution in the test, the error will be thrown. (Do not try to overcome it by enabling default inputs in gradle). The mocked method is suspended that is why the onBlocking is used — without the suspend method it would be on.
3. flow.test{} creates lambda within which the flow should be tested. In this lambda body, the test should test the required behaviour by calling appropriate methods and waiting for needed states.
4. awaitItem, as it says, waits for the following item from the flow. It can take a while to execute code and emit a new state in the flow. The test should compare the contents of the states and if they are in the correct order. awaitItem returns the result of the flow, so feel free to assert the correctness as it is needed.

The code seems correct as it progresses from Waiting to Running following the Finished state with the result and back to Waiting. However, the following error will pop up:

Module with the Main dispatcher had failed to initialize. For tests Dispatchers.setMain from kotlinx-coroutines-test module can be used java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize. For tests Dispatchers.setMain from kotlinx-coroutines-test module can be used

In our code, the app refers to the main thread by calling the Dispatchers.Main. However, the unit test does not provide any main thread. There is none. To go around it, the main thread can be mocked by setting the test dispatcher as the main dispatcher for coroutines. It has to be called before executing the test and disposed after finishing the test as follows:

After adding the test dispatcher, the test should run with a green check.

Testing multiple StateFlows

Firstly, the ViewModel should contain another StateFlow. To make it straightforward the ViewModel will possess two identical StateFlows. The jobs are run asynchronously on the same thread. All other functionalities are the same as before.

The usage of the Turbine API will change now as the test needs to deal with two flows at the same time.

The arrangement of the test at the beginning stays the same. However, the StateFlow is not tested via lambda. Creating lambdas for multiple states would result in chaotic code. Every state, which needs to be tested in the test case, can construct a receiver. The receiver needs to run in some coroutine scope. It is solved by using the runTest which provides us background scope to run testing coroutines.

Afterwards, the test can take some action to call required functions and wait for the events coming from the ViewModel in the form of the states, which are asserted and compared with needed expectations.

Do not forget to cancel or complete the flows at the end of the test. Otherwise, the test will hang / timeout will fail the test.

Conclusion

With the correct mocking strategy and the right level of abstraction, the turbine can help you test the ViewModels all the way through. Moreover, it is much easier to understand the code if the states represent the actual state, which is transformed into the UI. Make the code verbose as much as possible to make your life and life of others easier. Furthermore, testing uncovers many issues before releasing them to production.

Thanks for reading! Do not forget to clap and follow for more content!

Code repository:

More articles like this

Resources:

This article was previously published on proandroiddev.com