Unit Test in Android

Unit Test in Android programming based on TDD method

As an Android developer, you should be able to make sure that parts of the application you wrote work properly.
In Android programming, with the help of instrumentation & unit test, we can write a test for our project, which we are going to talk about in this article.

Unit testing Android applications can be divided into the following groups:

Local unit test(Java virtual machine platform testing) — Tests that can be performed on a JVM platform are called local tests. As much as possible, it is better to use local tests to test your software. Because local tests run on JVM, they run faster in time, especially than tests running on a real Android device.

Instrumented unit test (tests on a real Android device) — tests that are performed on a real Android system. If you want to test the code that requires the Android API and library functions, then you need to run these tests on your Android device. Unfortunately, this can make the test run longer.

The concept of TDD

Test-Driven Development, or TDD for short, refers to the stages of testing a part before it is implemented.
At first, this concept may be a little complicated and vague. In fact, we have always considered the importance of testing after writing code. But according to this method, writing a test happens before writing code. So understanding it may be a little far-fetched.
In general, we first write the desired tests, and then we create the required code for those tests.

In the field of test writing, we are faced with three colors, the meaning of which we will discuss here:

The concept of colors in testing

Yellow tests

Yellow Box Testing refers to tests used to check for warning messages. This name is chosen to match the use of yellow to indicate a warning. For example, when you write a test step to display an alert, you implement a yellow test.

Green tests

Green Box Testing refers to tests that determine the behavior of one department in interaction with other departments. For example, integration tests fall into this category. Integration tests are tests that look at several parts of a process. If all these parts together produce the desired output, this step is completed successfully. Suppose we have a login form and we want to check the steps for entering information and authenticating the user using the database. The step of testing the input information and the test of receiving information from the database can be independent tests. But if we want to examine the relationship between these tests together, this test falls into the realm of green tests.

Red tests

Red Box Testing refers to tests used to pass a section. If the tests fail at this stage, they are discarded and rendered useless.
All TDD tests are in the red test area. If a TDD test fails, it will be dropped from the project. Therefore, not all tests in this field will be used in the project until they are successful. Each section is implemented after passing these tests. Then the implementation phase continues until the tests are green.

Example of TDD testing:

Suppose we want to create a class that adds two numbers using one method. So in the first step, we have to write the required tests:

As you can see, the add method does not exist in the Calculator class. But we have created a test method and implemented the problem request in it. Now we have to implement the add method code according to the problem:

Now we do the test. If the test is successful, we go to the next step and do the same procedure again for the new request. With this programming pattern, you can significantly reduce the likelihood of program errors.
We have another image to interpret TDD, it is not bad to have it in the article:

To test the Local unit test section in Android, we use the JUnit5 and Mockito frameworks, and for the Instrumented unit test and UI sections, we use the Espresso framework.

Note that when you create a new project in the Android Studio environment, you will be faced with three sections, one of which will be the main and the main part of your project and the other two packages that you see in the picture will be for testing code. . The package that the test is empty for the first part is Local, which you complete using JUnit5, and the other package that is related to the Instrumented part is called android test. For this package we use Espresso.

To test writing we need a series of annotations
We have that you can see the application of each according to the following image:

In the following, I will comment on the small project I have prepared for a brief explanation of testing.

First, we follow the testing of the first part, Local:

To configure the gradle file, you must add a plugin to the build.gradle file at the project level:

Then add these two lines to add dependencies:

And don’t forget to add the apply plugin: “de.mannodermaus.android-junit5”.

Well, in the first step of starting testing, write the main class called My Utils in the main package of the program:

I will add 4 functions in this class, and because these methods are simple, we will not have an additional explanation:

Then go to the test package and create a class called MyUtilTest:

First, we will write the test for the first function:

Using Right Click and selecting Generate Option, you can implement a Test function by default and ready.
Well, as you can see, with the help of the @Test annotation and writing a method with the same name as the method you had in the main class, we will start writing the test for the first method.
The first method performs the addition operation. Takes an array of numbers and adds them together, then adds the sum plus 1 and outputs it.
We have a variable called actual Number that is supposed to include the actual output we have of the main method in the main class.
Its input is an array defined above-called nums.

I write the next variable called expected, which means the output we expect, and we will pass the number that is expected. (Sum of numbers 1,2,3) + we will have + 1 which gives output 7)
By selecting the Run option and selecting the test class, we will be able to run it, or by clicking on the green Run icon on the left side of Android Studio and selecting the first option, we will run the test:

You can see the output in the Run window, which has passed the test and its light has turned green!

Well, for the rest of the methods, write the tests the same way:

As a result, all tests pass and the light turns green:

Well, the Local test is over here and we will move on to the UI test.

Testing the second part, Instrumented with the help of jUnit4 and Espresso frameworks:

Well, we need to add the corresponding dependencies:

And add this line in the android tag:

This means that the build.gradle file at the end of your app will look like this:

You should create your classes and activities like this:

Create a layout.xml design layer for your activity below:

Then go to your activity and define all your views with the help of View Binding. We also write a function for the Button we have. As you can see in the design layer, we have 3 EditTexts with names and names

Gets the user as well as a password from the user and a condition for the user to fill in all the fields and otherwise show an error, we write:

Well, we will go to the test class that we created in the androidTest package and using the Espresso framework and defining the Rule and adding @RunWith (AndroidJUnit4 :: class)
To the class, we complete it as follows:

The on View method will be for defining a view and its input will be a method called withId to access that view ID.
The click method is also for the button that we have defined that has the ability to click and perform the desired action.
Running this test requires a simulator or a real device, and after passing the test you will be faced with this window:

Well, I brought you almost the generalities for writing a Unit Test on Android.

Thanks for reading! And if you enjoyed it, gimme a clap

Sana Ebadi | 19:28 PM Thursday, 8 October 2020