How we tested a Google Play application
Problem Statement: Case examples for Android applications
Greetings everyone! My name is Alexander Silinsky and I’m an Android developer at Kaspersky Lab.
As is well known, autotests simplify the testing process and relieve testers of the task of manually testing a significant percentage of application cases. Test automation significantly decreases the testing time and time-to-market (TTM) value.
In the context of automation testing, interaction with the application itself is often carried out through the Page Object pattern. You’ll see later how we put this into practice.
The Page Object pattern is mentioned in this article; briefly, it is a pattern in which a tested screen (regardless of the platform) is described as a set of interactive elements (buttons/icons/texts).
In the above example you can see three interactive elements:
- “Forward” arrow.
- “Back” arrow.
- Close button.
Also when you need to check the content on the screen you test you can also consider the title and description of the story page.
In terms of Android development we have Espresso and Appium as the most well-known instruments for automation testing. The biggest difference is that Espresso can test only Android applications, while Appium can test both Android and iOS applications.
There are different ways to detect elements on the screen. The most used are by text and by resource ID. If we’re testing our own application, it’s usually pretty easy to get the resource ID specified in the source code by the developer.
However, in today’s world, user interactions (or user scenarios) are not limited to just one application; there can be integration with another, third-party application, and system notifications from the application can also pop in. Often, if a company has a number of products with common/related functionality, they are promoted in every possible way within the application — for example, Kaspersky Internet Security has a banner with WhoCalls ads that lead to a page on Google Play.
Let’s look at the following test case:
- Open the main screen of the application.
- Click on the “Download WhoCalls” button.
- Make sure to open the page in Google Play (WhoCalls is in the title).
An experienced tester will immediately notice various so-called “negative cases”, the most obvious being when the user is not logged into a Google account: instead of the desired product page in Google Play, the following screen will be displayed:
In this case the user must authenticate by entering their login/password. Also, from time to time Google Play may ask a user to re-enter their login/password due to suspicious activity — these scenarios must simply be dealt with as part of the autotests. How do we test such applications if we don’t have access to the source code.
Selecting a tool for testing third-party applications. Defining interactive elements
Using only Espresso is not enough to test third-party applications, we need to use an additional tool called UI Automator. It’s also worth noting that using Appium might solve this problem, because it uses UI Automator “under the hood” for the Android platform. But unlike Espresso, using only Appium limits testing to the black-box method; for example, we can’t identify elements that are not visible on the screen, idling resources, etc.
UI Automator is a UI testing platform suitable for functional UI testing between applications on the system and installed applications. Automator’s UI APIs allow you to interact with visible elements on the device, regardless of which application (screen/window) is in focus.
Therefore, we can interact with almost any application, even without access to the source code.
The way to define an element on the screen is similar to Espresso, but with a different syntax. In most cases, an element can be identified by text and ID.
You can read more about UI Automator and its features in the documentation.
In our case, with the Google account login, this method will make the test fragile, because if the text on the button changes (which can happen quite often if, for example, Google wants to conduct A/B experiments with the button) or the locale on the device has been changed.
You might think that the guaranteed way to identify an element is by its ID-key, which is generally considered stable, as it is rarely changed. But in reality it is often obfuscated in the release application configuration, so it can be useful to use all available options.
Here are several (but not the only) ways to define a screen element:
- UI Automator Viewer.
- Third-party applications (aka Developer Assistant).
- Dump.
Let’s take a look at each of these tools and break down their pros and cons.
UI Automator Viewer
UI Automator Viewer is a tool for determining the layout hierarchy of elements on the screen, as well as the attributes of these elements themselves.
This tool is available in the Android SDK by default.
As you can see in the image above, the element ID is obfuscated, so we need to use the text and/or the element’s view class to define the element.
Third-party applications (aka Developer Assistant)
If for some reason you don’t have access to the Android SDK, you can use the Developer Assistant app available on Google Play. Once the app is configured, you will be able to define attributes of elements on the device, similar to UI Automator Viewer.
On the plus side, it allows you to define element attributes directly on the device without access to the Android SDK. However, it does not know how to define elements for system dialogs and notifications.
Dump
You can dump the content from the screen into a separate file using the UI Automator features.
Before using this command, you must open the screen whose information you want to retrieve.
Writing an autotest for a Google Play example. Kaspresso, Kautomator
Moving on to the implementation of the autotest, we need to choose the tool on which we will write the autotest. From the most popular ones we can highlight Espresso and UI Automator.
Here’s an example of how test would look like using these instruments:
As you can see, different syntaxes are used to interact with different elements when working with them. There is a popular open source framework, Kaspresso, which allows you to erase these syntax differences and maintain a unified style when writing autotests. Under the hood, Kaspresso uses Kakao and Kautomator — DSL wrappers over Espresso and UI Automator — providing an intuitive interface.
Let’s take a look at an example autotest written with Kaspresso:
As you can see, we use the Page Object pattern to describe the screens. Here’s the code for our page objects:
The KScreen class is used to describe elements using Kakao, and the UiScreen class for describing using UI Automator.
Now the code is more readable and maintains a unified approach when writing test cases.
Kautomator isn’t just a DSL wrapper over UI Automator; the benefits are faster autotests and increased stability through interceptors support.
Kaspresso offers a lot of benefits over using only the Espresso + UI Automator tools:
- ADB commands support.
- Declarative steps.
- Reports and readable logs to analyze tests.
- And even more…
You can learn more about this framework right here.
Conclusions
We’ve seen how to test a third-party application (using Google Play as an example), figured out ways to determine the ID of on-screen elements of a third-party application, and implemented the test case itself using Kaspresso and Kautomator (essentially a wrapper over UI Automator).
The Kaspresso framework also has its own series of tutorials for autotest enthusiasts and for those who want to start writing autotests using Kaspresso! I hope this article was useful. If so, check out the Kaspresso GitHub project, and leave a star if you want.
Also, we have a Discord Server, feel free to ask any questions directly to the people who maintain the framework!
And furthermore, we welcome you to read our previous publications about autotests on Android:
