Principles we Use While Writing Unit Tests for Android Apps

Believe it or not, only a minority of Android developers uses Unit tests or tests at all. That brings up a question – how can they be sure that source code they produce works. Many companies don’t use them by default, and the client in the most cases is not willing to pay for extra hours just for unit tests. Unfortunately, that mistake can be costly later, when something happens in the wild, and the app is already in production.

Unit tests are the fundamental tests in your app testing strategy. By creating and running unit tests against your code, you can easily verify that the logic of individual units is correct. Running unit tests after every build helps you to quickly catch and fix software regressions introduced by code changes to your app. Android official

We like our app to work correctly (at least we aim for that), so we are aware of the risk in which we could involve our client if we don’t test everything that we produce. Because of that, we are trying hard to find time for unit tests even if a client is not willing to take extra hours for that.

I remember one situation that happened two years ago where I didn’t write tests and we deployed a new Android release. It was a release with a few new features, and that app went through QA department which tested every single use case with all those features. In the Android department, we got a green light. Great, let’s submit it to Google Play… a few hours later emails started coming to our support department. What was the problem? We didn’t have a test for login functionality and it didn’t work anymore. That happened because the QA department tested features while logged in and none of them checked the fundamental thing like login. After that incident, we started writing tests for everything.

Here in this article, we will try to explain a few fundamental principles (that we try to accomplish) for writing excellent unit tests for Android apps, so let’s dive into it.

#1 Make them independent

The most frequent mistake many developers are making is the fact they create a unit test that is dependent on some other unit test. With that approach, if one unit test fails, all tests that depend on it will fail as well. The right way is to be sure that every unit test is testing only one thing and doesn’t depend on any other test.

For example, let’s say that you would like to test if your list has above the minimum number of items and if it is below the maximum number of items. It’s the wrong approach to check both things in a single method. Test for that use case should have at least two methods, one in which you would test for the minimal number and the second method which would test for maximum. If your test has both checks in the same method, you are doing something wrong.

Wrong way

@Test
public void checkIfListIsInRange() {
   assertThat(list.params.size).isBetween(min, max);
 }

Right way

@Test
public void checkIfListIsGreaterThanMin() {
   assertThat(list.params.size).isGreaterThanOrEqualTo(min);
 }

@Test
public void checkIfListIsLessThanMax() {
   assertThat(list.params.size).isLessThanOrEqualTo(max);
 }

 

#2 Make them readable

Every single test should be readable and straightforward, otherwise, you know what will happen if test is not legible? Well, when a new developer executes that test for the first time and that test fails, it would be easier to delete the test than trying to find the problem inside the test.

It’s so much better and efficient to write it readable in the first place. It will help you to avoid so many problems later. When we are writing tests, we have a straightforward rule for readability. We write the comment only on test class, if we have to comment on every method that is a red flag showing that test is maybe too complicated and we should rewrite it.

The name of the test method should describe what the method is all about and if that is not enough, well, we have a problem there.

#3 They should fire automatically

Probably you already know about continuous integrations and how that can help your tests to fire automatically when something is pushed to the GitHub. Use it, if you don’t have that process done in your organization, leave everything that you are doing right now and fix that.

I used to say, ok I don’t need continuous integration because I always execute tests when some task is done, but that is just a theory. A few times when I was in a hurry fixing some bug, I just pushed without executing it thinking nothing wrong could happen. Don’t forget it is always better to have the system that helps you avoid mistakes like that than to not have it at all.

Please write unit tests!

Personally, I care about projects that we are building inside our development agency, and I care for them to have at least 80% of unit tests coverage, but I also care for other companies. Why? Well, if I am using some other app on my Android phone, I don’t want for that app to crash once in a while. There is nothing more frustrating than an app that crashes and you can only guess what is the reason behind it. As a developer, I always, naturally, find a few reasons why the app crashed, and in many cases it could be avoided if developers were just careful enough and wrote tests.

Either you have your own idea and you want to consult with our experts or you just want to share your opinion, feel free to Contact Us
Alen Huskanović
Alen Huskanović
A guy with huge interests in technology and sharing his knowledge with interested people. He is a co-founder of a digital agency Async Labs where he was helping companies all around the world to become present on the Internet with digital marketing strategies. Using growth hacking actions he had a couple of successfully campaigns where he achieves an impressive number of followers on different social media channels.
Lets's do some work
Share
Tweet
Share
Pin