A User interface test involves interacting with multiple apps and verifying that the app behaves fine when the flow passes through other apps or through the System UI. An excellent example of this would be the Android messaging app where the user can enter the message which then launches the contact picker so that the users can select the recipients to send the message and then returns to the app to submit the message.

This blog covers how to write UI tests using UI automator testing framework which is provided by Android Testing Support Library. The UI Automator API interacts with the visible elements of the device irrespective of any activity on focus. We can test all the UI components by using the convenient descriptors such as the text displayed in that component. UI automator runs tests on devices using Android 4.3 (API level 18) or higher.

The UI Automator testing framework is an instrumentation-based API which works with AndroidJunitRunner test runner.

Setting up UI Automator:

Before writing tests with UI automator we have to configure our test source code and project dependencies.

A dependency reference to the UI automator library has to be set in the build.gradle file of our Android app module

dependencies {
…
androidTestCompile ‘com.android.support.test.uiautomator:uiautomator-v18:2.1.1’
}

Optimizing UI automator testing involves inspecting the target app’ UI components and ensuring if they are accessible.

Inspecting UI on a device:

The first step would be inspecting the UI components visible on the device. We can check the components which have visible labels, content description values or both.

To do this, a tool called UI automator viewer is used. This tool provides a visual interface and inspects the properties of UI components that are visible on the foreground of device. Using the data given by the UI automator viewer tool we can create fine grained tests with UI automator.

Steps to use UI automator viewer tool:

• Launch the target app on device.
• Connect the device to the development machine
• Open a terminal window and navigate to <android-sdk>/tools/ directory.
• Use the below command to run the tool.

  $ uiautomatorviewer

Steps to view the UI properties of application:

• Click Device Screenshot Button in uiautomator viewer interface.
• Mouse hover the snapshot in the left panel which shows the list of UI components identified by UIautomatorviewer tool.
• To see the UI components which cannot be accessed by UI automator click on Toggle NAF nodes button however only limited information may be available for these components.

Ensuring whether the activity is accessible:

The UI automator test framework works better on android apps. There is no need to implement accessibility support when UI elements of type view is used from SDK as these classes have already done that.

Some apps using custom UI elements won’t provide accessibility support. If the app contains instances of a subclass of view which is not from SDK, then we can add the accessibility features to these elements by doing the following steps:

• Creating a concrete class that extends ExploreByTouchHelper.
• Associating the instance of new class with a custom UI element by calling setAccessibilityDelegate().

How to create a UI Automator class:

UI automator test class should be written as a Junit 4 Test class. We have to add the @RunWith(AndroidJUnit4.class) annotation at the beginning of the test class definition. We have to implement the following programming model in UI automator test class:

• To get an UIDevice object to access the device we want to test, we have to call the getInstance() method and pass it an Instrumentation object as an argument.
• To get an UIObject object to access the UI component displayed on the test device, we have to call findObject() method.
• To Perform a user interaction on that UI component, we have to call uiObject method. If we want to perform a multi touch gesture we have to call performMultiPointerGesture(). If we want to edit a text field we have to call setText() method.
• We can also repeatedly call getInstance() and findObject() repeatedly in order to test complex interactions which involves multiple UI components or multiple user actions.
• We have to check if the UI reflects the expected behavior after peforming the user interations.

Running UI Automator Tests on Emulator:

We can run the UI Automator tests from Android Studio by specifying the AndroidJUnitRunner as a default instrumentation in our project.

Myth 1: Automation replaces Manual Testers.

Reality: After the scripts are developed, the common misconception is that we can replace the manual testers with Automation, but this is not true. Automation is a program which will test the flow of the system. Even a small defect can be missed if we don’t write scripts to look for it, but this can always be found during manual test execution. Also, if the application being tested undergoes changes, this often results in the failure of scripts and the manual tester must test the changes until the scripts are updated.

Even though automation reduces the amount of time taken by manual testing, one needs to spend time on test results analysis to make sure that automation has not missed out any critical defects.

Solution:

• We always need a human brain to analyze the test results. Robots cannot replace humans in automation testing.
• For applications, which are changing frequently, automation testing can only be used as a reference and not as a replacement for a manual tester.
• Automation should be used for static applications which are independent of other modules and which need to be regression tested.

Myth 2: Automation executes fast whereas manual testing executes slow.

Reality: Automation runs faster than manual testing but sometimes when the properties involved for the object are not straight forward, then automation testing would take time in identifying those objects.

For example: If a page has multiple headers and has similar properties, then automation might take some time in identifying those headers whereas manual tester does an easy check for its existence.

Preparation of Test data also involves time because it involves writing a logic for Automation testing while manual tester does it faster because they know the test data to choose for the application which in turn increases the execution speed.

While testing, applications communicating with multiple systems both manual and automation takes the same time to execute because of the dependency on external system.

Solution:

 One must take an account of the time needed for execution, the complexity of the application and number of external system involved. All these must be done during requirement analysis. A feasibility study must be done on the time taken for execution and effort spent in automating application.

• All the stakeholders should be made aware of the automation effort involved.
• The estimation effort should be calculated by taking the following factors into consideration: Objects complexity, flow of the system, time needed to build the scripts and lastly the execution time of automation verses manual testing.

Myth 3: Users just need to click a button to execute the automated test cases.

Reality: When automation is completed and delivered to end users, they assume that scripts can be executed without any change in test data but this happens only in a rare situation. End users should also spend their time in execution. They should be aware of the flows of the application, keywords used in the application and the test data needs to be given.

Solution:

 We should have a periodic discussion about the test case flow and test data to the end users which will avoid wrong expectations.

• We should also understand the test data used which can be constant and which can be used as an input. This will minimize the number of data inputs needed for each test case.

Myth 4: Expecting 100% automation test execution without any failures.

Reality: Automation is also like application development with lot of limitations and hence executing all scripts without errors is impossible. There can be many reasons like slowness of system, Environment outage, data issues, UI changes etc.

Solution:

 End users should understand the reason of the failure before passing it to the automation team. This helps in understanding the flows of the system and the inputs needed for it rather than depending on automation team.

• Automation is ideal for stable systems or for the systems for which the development is complete.
• We must make sure all test cases are updated with latest data and there is no factor affecting the system execution.

Myth 5: When automating a new application, one can study the existing framework and this doesn’t need time to invest on.

Reality: Practically, Automation is not easy. It needs a lot of time, money and mainly patience. If used in a right way, automation can help organization in a big way. Testers need to understand the domain, the test cases to be automated, choosing the right framework to build a strong foundation in automation.

Automation is also like an application development which needs a lot of testing. The automation scripts must be tested thoroughly with all set of test data both positive and negative. Improper testing or partly tested tool results in failure of scripts and leads to the lack of confidence in the tool.

Solution:

• Understanding the application thoroughly which needs to be automated would give a better clarity to the scripts.
• While setting the timeline for automating the scripts, the time needed for requirement gathering, design, coding and testing should also be considered.
• Discuss with Manual testers and developers on the key areas before deciding the suitable framework and tool.

Conclusion:

Automation testing can deliver long-term benefits but not suitable for immediate results as the scripts should be constantly updated and maintained. We should also understand that automation is not only a magic tool to meet the deadlines of execution but also has its own limitations hence automation testing is highly effective and can yield best results when it is combined with manual testing.