👨🏼💻Testing the modules of your MVVM + Clean Architecture Android project Part 2: Testing the Use Cases[Beginner]
Hi wonderful people, we are back at it AGAIN, this time with the second part of our article series. In this short article, I will be explaining shortly and simply how to implement use case test cases. Without further ado, let’s get right to it.
Introduction
As we explained in the first article of this series and as I have been repeating over and over again (its getting kinda dull tbh), using MVVM and Clean Architecture has immense benefits for your android project development, from the development and code quality, to the ease in scalability, debug and testing.
In the previous article, we created a simple android movie app using MVVM / Clean Architecture and many more methods. You can access and check it out in this link. Now let’s get to Use Case testing!
Use Case Testing
In order to move on to the use case testing, its probably a good idea if we give a short explanation of what actually is a use case.
Alright so in MVVM methodologies, we actually have Models, Views and ViewModels where we extract our business logic. However, this is not always a good idea, as the project gets more complicated to manage and test with the increase in scale. Therefore, we use use cases instead of view models to store the business logic, and we keep them in the domain layer of our Clean Architecture so that they are encapsulated and protected from the changes in the other outer layers. But how do we test them?
Development
The first step we have to do as part of this testing implementation process, would be to actually include the dependencies needed for the testing process in the app build.gradle file.
//Testing
testImplementation 'junit:junit:4.13.2'
testImplementation 'org.mockito:mockito-core:2.11.0'
testImplementation 'android.arch.core:core-testing:1.1.1'
testImplementation "com.google.truth:truth:1.1"
// For Robolectric tests.
testImplementation("com.google.dagger:hilt-android-testing:2.28-alpha")
// For instrumented tests.
androidTestImplementation("com.google.dagger:hilt-android-testing:2.28-alpha")
// ...with Kotlin.
kaptTest("com.google.dagger:hilt-android-compiler:2.40.5")After we have included the dependencies and synced the project, we will start the process.
We go to the use case we have implemented in our domain module, click the little yellow bulb that appears in the class name and say create test. Alternatively, you might opt to do this manually, but this is the best way as the newly generated test class will be placed in the right test folder automatically.
The upper picture shows how you can generate the testing class. We pick JUnit4, but you are free to select JUnit5 as well. After creating the test class, we are now ready to create the test cases.
Movie List Use Case Test:
The movie list use case of the project we created and showed in the previous article is as follows:
As you can see, we inject the movie list repository in it, so in order to create a test case for this use case, we need to create a fake repository with the information we need to ‘feed’ to the use case.
Hence for the Movie List Repository I have created a fake repository as follows:
We cannot use the actual Movie List Repository as we need to provide some mock data to the use case, but we can extend the actual repository in the fake one we created so as to use the functions declared in it.
In our Movie List Use Case Testing class, we declare the fake repository and pass it as an argument in the use case before we start testing.
After that we create 2 tests, for a correct and an incorrect return of the movie list in every case.
We search for movies names “title”, as we actually named the titles in our dummy data “title1”, “title2” and “title3”. We want to see if we are actually getting a result for this title, hence we use assertThat method and compare whether the title of the first result is equal to “title1”. It should return true.
Similarly, we create another test case that evaluates the case when we get the incorrect movie. We get two passed test cases as shown below.
Movie Details Use Case Test:
Similarly to the previous test cases, we also create test cases for the movie details use case.
In this case we create a repository extending the Movie Details Repository and containing dummy data to feed to our test case.
In our test case, similar to the previously explained and created test cases, we initialize the Repository we just creates, and then prepare the test cases.
Similarly to the other test cases, we use assertThat method to determine whether the output is the one we expect or not.
The results of these test cases are as follows:
Conclusion
In this article, we shortly explained how to create simple use case tests by creating Mock Repositories containing the mock data we need to feed to our use cases and observing their behavior and / or results. In the upcoming articles we will deal with other unit test cases, but until then, stay healthy and see you soon!
