Testing the Un-Testable With Android Architecture Components - Room Queries
Test Driven Development they said ! Directly test your business logic, your domain layer they said. Then go ahead with testing your UI. Domain layer, Presentation Layer and Data Layer, i.e Separation Of Concerns they said.
Wait ! What? Data Layer. What about the Data layer ? What plans do we have to test this poor fellow. Fakes or Mocks are just arrangements we make for the domain layer to run in the test environment.
What about the queries we write to fetch and write data from/to the local db. How do we test if they have been correctly written. Interesting question to think upon, Right?
Here comes Room, With a Boom! Room provides a way to create in-memory databases and execute queries on the main thread.
Let’s See all this in Action.
Include the necessary dependencies inside app/build.gradle:-
Before seeing the test code, lets have a look at our Room Dao interface. For simplicity, I have applied all this to a Note Making app. So here is our NotesDao interface.
So we have queries to fetch, insert, update and delete notes from/to our table. Let’s have a look at our tests now. Please Note as these are instrumentation tests you would have to write them under androidTest source set.
Now let’s step by step understand how our test cases have been written.
The very first line :-
InstantTaskExecutorRule is a JUnit Test Rule that swaps the background executor used by the Architecture Components with a different one which executes each task synchronously.
Cool , now lets see how exactly are we Creating an instance of Room Database in our test environment before running every test.
inMemoryDatabaseBuilder method helps us to create an in-memory room database instance while allowMainThreadQueries() helps us to run the database queries on the main thread. Pretty straight forward isn’t it ? And yes after every test we are closing the database and re-creating it again before Running another test. Testing in isolation, you see ;) .
Ok, so now let’s straight way jump to our very first test.
As you can see in the very first line we are fetching all the notes from the table using an instance of NotesDao created in the before method and then checking if we are getting an empty note list or not as we are fetching this from an empty table.
You would be curious to know what exactly is the use of Custom LiveDataTestUtil class. Well, as getAllNotes is giving us a LiveData object which has a list of all the notes, it is important for us to extract the notes list from this LiveData object so that we can perform assertions on the appropriate data type.This is what LiveDataTestUtil does. Here is how it looks.
You can put this directly under your util package.
Now let’s see the test case to check updating a particular note.
In the very first line we are fetching a fake Note with details like title, description and date modified and inserting this in the table via insert method of notesDao. Then we are updating the title of this note and calling update method of the dao to update the note in the table. Then we are fetching the same updated note by calling getNoteById method of the dao and checking if the fetched note has the updated title or not.
So, Yeah! This was about the Test Cases. Skipping explanations of the remaining test cases as they follow the similar approach .
Before Saying Good Bye let’s run our test cases.
Bingo! They pass :). But wait, don’t get excited. This is not what Tests are meant for.
Well written tests are meant to capture any error or bugs gracefully and meticulously just like Sherlock Homes catches the culprits. So let’s see if our tests are sharp and intelligent like Sherlock Homes ;).
Let us suppose we have newly migrated to Room and have copy pasted a room query from somewhere to our code. In this case let’s suppose a query to fetch something. And now we want to transform it to our use. But as the release date is approaching near, we are in hurry and miss the fact that the original query also had a maximum limit of 3 records which can be fetched.
Let’s see if our tests pass now.
Oh No! (Actually, Oh Yes!) the test case to check row count fails :( . This means our test cases found the error in the query for us.
“Massive Kudos to our Room Tests then”
So this was about testing if your Room database queries work correctly or not by Testing the Dao classes thereby empowering our Data Layer to proudly tell the Domain layer and the Presentation Layer that “Yes, I am also on the verge of becoming Bug Free”
Here is the link to the github repo. https://github.com/TechnoZoom/NoteMakingMVVMDataBinding/tree/roomdaoTests
Part 2 of this series is out.
Follow me on twitter https://twitter.com/akapil167 to get regular updates from me.
“Start pampering your Data Layer Now :) ”
