DEV Community

Cover image for Testing in Android. Unit test check list
Tristan Elliott
Tristan Elliott

Posted on • Edited on

3

Testing in Android. Unit test check list

Introduction

  • Now that I have officially released my first app, which can be found HERE on the Google Play store. I want to add more features to my app, however, I think the next best step is to add some tests. So, this series is going to be a practical series dedicated to understanding testing in the Android framework.

The checklist

  • As I have finished my instrumented tests for now, I have moved on to unit testing my code. Below is a checklist that I have developed for unit testing. This is an example from testing my repository layer but it can be applied to other features/layers as well.

1) Identify the dependencies : This is the first and arguably the most important when unit testing.

shows the dependency injection pattern

  • If you look at the image above you will notice the red circle where I have identified my dependency for this class. Also, notice I am implementing the dependency injection pattern. This will allow us to easily test the repository class later on.

2) Set up the tests :
initial test setup with mockito

  • This step is a rather large one but it involves us first creating a new class in the unit testing folder. Then we identify what is being tested, private CalfRepository calfRepository;. next we identify what the dependencies are, private CalfDao calfDao;. Then we use the @Before annotation to set up a method to run before every test. Then we use Mockito to set up a mocked object of the dependencies, Mockito.mock(CalfDao.class);. We use mocked objects because they allow us to test our repository layer in isolation. With a mocked object we can control with 100% certainty what each method will return. The last part in this section is to create a new instance of whatever we are testing, for this tutorial it is, calfRepository = new CalfRepository(calfDao);.

2) Implement the tests
Test example

  • Of course the logic you use for your tests will change. However, I marked what should stay the same with red Xs. In order for us to create a test, we have to mark a method with the @Test annotation. We also mock the methods that are being called in our dependencies, this way they always return what we want them to. The reliable return values allows us to test the repository layer in isolation. The mocked method is done by, Mockito.when(calfDao.properInsert(Mockito.any(Calf.class))).thenReturn(returnedData);.

3) Rinse and repeat : Testing a very repetitive, so once you have done it for one method, do it for the next method and so on.

Conclusion

  • Thank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on Twitter.

Top comments (0)

Great read:

Is it Time to go Back to the Monolith?

History repeats itself. Everything old is new again and I’ve been around long enough to see ideas discarded, rediscovered and return triumphantly to overtake the fad. In recent years SQL has made a tremendous comeback from the dead. We love relational databases all over again. I think the Monolith will have its space odyssey moment again. Microservices and serverless are trends pushed by the cloud vendors, designed to sell us more cloud computing resources.

Microservices make very little sense financially for most use cases. Yes, they can ramp down. But when they scale up, they pay the costs in dividends. The increased observability costs alone line the pockets of the “big cloud” vendors.

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay