Introduction to Android UI testing

Testing, often overlooked is an integral part of software development. It is used to automate the testing process which if done manually would cost time and effort. Moreover, doing manual testing might lack reliability as it could naturally skip some possible inputs to test. But developers most of the time shy away from writing test cases because they want to avoid it’s implementational complexity.

Any complex problem can be easily solved if broken down to small sub problems and solved one after another. In this story we will discus the same approach for formulating a user interface(UI) testing for Android platform. We will discus about the fundamental block of a test. Find, Perform, Check. Espresso framework will be used to write test cases.

Espresso?

I have an imaginary friend called ‘Max ’. One day I was developing a simple Android application while Max was living his ‘American Dream’. I become very busy developing. So, I ask Max to pause his dream for some moments and help me to test my application. It is a very simple app which has two activity and a button on the the first activity. Touching the button will simply open the second activity. Pretty simple right? I give 3 instruction to max.

1. First, find the button.
2. press it.
3. Finally, check if second activity has appeared.

Just think about these instructions. These are general instructions for testing more or less any UI interaction . We can write a fresh pseudo code for these instructions.

1. findView(button);
2. perform(click);
3. isDisplayed(SecondActivity);

If I can write such code and execute it then Max doesn’t have to do anything but to return home timely.

darn :/

To be able to write such code which is a basic test case we need a framework (to lessen our hard work of course). Out of many frameworks I prefer Espresso. Espresso is open sourced by google. It is lite weight and has a very easy learning curve.

Espresso has three basic components:

• View Matchers: Which allows to find view in the current view hierarchy.
• View Actions: Which allows to perform actions on the views.
• View Assertions: Which allows to assert state of a view.

Can we ‘one to one’ map Espresso’s components with the testing instruction we have discussed earlier? The answer is yes.

Let’s use these components to transform our pseudo-code to real java code. Earlier we talked about breaking down problems to sub problems. So, First, consider the first instruction.

Find out a button from first activity’s layout.

onView((withId(R.id.button)));

onView() is a Espresso framework method which is used to get a reference of a view. We can use withId() or other properties e.g title of the view to get the view.

Then, perform an action on the that view

onView((withId(R.id.button))).perform(click());

perform(click()) executes a click on the view.

Finally, let’s do a quick assertion of whether a view is displayed after performing the click. Assertion is a expression which is true if testing doesn’t find any bug or false otherwise.

onView((withId(R.id.layout))).check(matches(isDisplayed()));

We first find the view which should be displayed after the click. layout is the id for Second Activity’s root parent view e.g A Linear Layout. We put a check() method provided by Espresso to match layout with the current view by calling matches(isDisplayed()).

We are done with writing test codes but we need a class that will hold this code and can be compiled. Android studio creates a separate default package for UI or instrumental test. We will create a new java class there. I have named the class GoToSecondActivityUITest. Remember to follow a easily understandable naming style.

GoToSecondActivityUITest

Now, we need to tell Android studio to launch the app and test the UI from this class. For that purpose we need to mention it somehow. Java uses Annotations to do so. Java Annotations allow us to add metadata information into our source code. So lets add @RunWith(AndroidJUnit4.class) at the start of the class.

@RunWith(AndroidJUnit4.class)
public class GoToSecondActivityUITest {
}

Above ‘@RunWith’ is an annotation. (Don’t forget to add support-annotations library in the gradle).

Test codes must be mentioned as they are test codes. Otherwise compiler will not understand and treat it as a normal code. So by annotation we are going to highlight test codes.

We will add @Test prior to the function definition.

@Test
public void buttonClick_goToSecondActivity() {
}

The function buttonClick_goToSecindActivity() is now assigned as a test case.

Lastly we will add a @Rule annotation.

@Rule
public ActivityTestRule<MainActivity> mainActivityTestRule =
        new ActivityTestRule<>(MainActivity.class);

This is added to tell the compiler which activity to run test on.

Finally, our testing code will look like this,

We can execute this test by right clicking on the class file and choosing ‘Run’.

This example is just a starting point for UI testing. Developers who haven’t tried can finally get their hands dirty by following through. From here I will advice you all to go for moderately complex example. Thank you all and keep coding.

“Long live sacred Bangladesh.”

“বাংলাদেশ দীর্ঘজীবি হউক”