How I Destroyed My Stereotypes About Autotests, or My Path from Appium to Kaspresso

Hi all!

My name is Sergey Dudarev, I am the head of the automated testing department at Mobile Development Department at Kaspersky Lab” In this article, I want to tell you how I went from Appium to the open-source framework Kaspresso, where I started, what discoveries I made for myself, how my stereotypes were destroyed and what conclusions were ultimately made.

How I came to choose Appium

When I moved to mobile testing, I faced the choice of an automation tool. I chose between native tools (Espresso, Kaspresso) and Appium.

At that time, there was little information about Kaspresso, from what was found on the Internet, this is README.md on github and a few articles that didn't provide enough information to understand all of its capabilities.

The only options left for me are Espresso and Appium.

The latter was more popular among my colleagues from neighboring teams.

After talking to them about their choice and reading several Appium vs. Espresso comparison articles, I have identified the following advantages in favor of Appium:

1. Appium has a lower entry threshold compared to native tools. It turns out that manual testers without experience in writing code will find it easier to write their first test, which will start to bring benefits, which means that interest in automation will grow. I have often met manual testers who lost such interest because they could not figure out a complex project and write their first test. I have also met those who started writing autotests in projects with a well-thought-out architecture, composing their first tests as a constructor from ready-made steps – their interest only grew, and they delved deeper into automation, reaching the level of a test automation specialist. Therefore, the lower the entry threshold, the better.

2. With Appium, you can interact with third-party applications. In Espresso, for example, there is no such option. Android has a separate tool for this, UIAutomator, but I wanted to have a similar API for working with both your own application and a third-party one. This particular advantage was key for me, since the specifics of the project imply a lot of interactions with third-party applications, and with the Android system itself.

3. With Appium, you can write one test for two platforms at once (Android and iOS), unlike native tools. This is also a significant argument in favor of appium, because it looks like we can solve two problems with one tool.

So my choice fell on a stack of python + pytest + appium.

Time for experiments

For about half a year I was automating tests using this stack, and everything seemed to be going well, but I was becoming more and more interested in Kaspresso – more and more information and positive reviews started appearing about it, and tutorialwhich explained the capabilities of the framework step by step.

At that time, I had no idea how suitable it was for me, since the project has its own specifics. I decided to write several tests on Kaspresso, so to speak, optionally, without compromising the automation of my project.

How my stereotypes were destroyed

Having taken a link from colleagues tutorial on Kaspresso, I started getting to know it, simultaneously implementing the framework into my project. It turned out that it is not difficult at all! It is enough to add several dependencies and create a package with tests. This is described in detail in the section integrations.

Writing the first test turned out to be quite easy thanks to the clear and concise Kotlin DSL. If you look at the test code, it becomes immediately clear that on the WizardAgreements screen we press the “Next” button, and then on the permission request screen we check that this button is visible:

@Test
fun requiredPermissionTest() =
   run {
       step("Agreement Screen") {
           WizardAgreementsScreen {
               continueButton {
                   click()
               }
           }
       }
       step("Required permission screen") {
           RequiredPermissionScreen {
               continueButton {
                   isVisible()
               }
           }
       }
   }

When I wrote the first test, my first stereotype about the entry threshold was destroyed. For a long time I was sure that in order to write a native test, you need to immerse yourself in kotlin (which I was practically not familiar with), deeply understand the structure of the application being tested. In fact, starting to write autotests on Kaspresso is no more difficult than on Appium, and in my opinion, it is even easier. You can see for yourself by taking the lessons in tutorial by Kaspresso.

When it came to interaction with third-party applications, my second stereotype was destroyed. I believed that native tools are not suitable for these tasks, but as it turned out, this is true only for Espresso. If we want to test with it, then for interaction with other applications it is worth taking another framework – UIAutomator. However, Kaspresso is based on these two tools and provides convenient and functional wrappers over them. Thus, you do not need to use anything else – this framework covers all needs. In addition, we get a single style in our tests when interacting with both your application and third-party ones.

Appium also uses UIAutomator as one of the options for interacting with applications.

The possibility of writing one test for iOS and Android using Appium remains no less controversial. On the one hand, this is true: you can write one test in one language that will run on two platforms, but in fact, two applications often have different UX and UI (due not only to inconsistency in design, but also differences in OS) and different locators for elements. As a result, instead of a single code for two platforms, we get many if-statements in the test code to separate the logic by platform, which makes the test cumbersome and inconvenient to debug.

I think we shouldn't limit ourselves to one programming language for solving different problems. It's better to use the language that suits a particular case, rather than the one we know best. There may be exceptions to this statement (for example, experiments that need to be carried out in a short time), but the essence remains the same.

More to come

The more I delved into studying the capabilities of Kaspresso, the more sympathetic I became to it. The first thing that comes to mind is the well-thought-out architecture of tests. It is based on the page object pattern. When writing tests, you don’t need to think through the basis of their architecture, it is enough to follow the concept embedded in Kaspresso. The next thing is that Kaspresso out of the box provides what I had to come up with and implement myself in my project with Appium. For example:

1. adb

To interact with the adb server in a project with Appium, I had to write my own implementation that executes adb commands via the subprocess python library. In Kaspresso, it is enough to access the adbServer interface, call the performShell method, which executes shell commands in adb (you don’t need to write the entire command, just write everything that comes after shell), and pass the command we want to execute to the method:

adbServer.performShell("pm list packages")

In response, we will receive the result of executing this command.

adbServer also has methods performAdbwhich executes adb commands (we pass everything that comes after adb in the command there), and performCmd – executes command line commands on the host from which the tests were run.

In Espresso there is no possibility to interact with adb at all.

2. Wrappers of adb commands

Ready-made wrappers of adb commands save time on searching for how to compose these commands. Moreover, they eliminate the need to implement methods that execute these adb commands in your project. For example, to disable the Internet on a device, it is enough to call:

device.network.disable()

There is no need to know and execute the commands “adb shell svc wifi disable” and “adb shell svc data disable” separately. Also, the Devices class has a large set of methods for interacting with the Android OS: for example, you can emulate incoming calls and SMS, install and remove applications, change the language. You can read about all other capabilities of the Devices class Here.

3. Autoscroll

Kaspresso has a scroll function implemented to the element we are going to interact with. This mechanism allows you not to think about the fact that on some screens the element may not fit and be beyond its boundaries. If necessary, Kaspresso will scroll to the required element itself. This makes tests more stable and speeds up their writing, because now there is no need to implement the scroll method in your project – and then separately think about where to add its call before clicking on it, for example.

4. Working with permits

There are several ways to grant permissions that Kaspresso supports. The first is automatic, when installing the application, the second is when using a custom scenario, through the UI. Here it is worth focusing on the second option. In the case of Appium, if we have a task to check the request and application of the permission, we need to find a locator suitable for it and write a method that will search for and accept it on the page.
In the case of Kaspresso, we only need to call an already implemented method that will check for the presence of a dialog and an example of a permission if it exists:

device.permissions.apply {
   flakySafely {
       Assert.assertTrue(isDialogVisible())
       allowViaDialog()
   }
}

5. Screenshots

Our application must support multiple localizations, so there is an important need to view how the application screens look in different languages. To solve this problem, as well as to conduct a design review, Kaspresso provides another ready-made solution out of the box. Just look how little code you need to write to take screenshots from the application screen in 12 languages ​​and save them in the sdcard/Documents/screenshots/ folder:

WizardAgreementsScreen {
   continueButton {
       isVisible()
       captureScreenshot("AgreementScreen")
   }
}

There are two ways to take screenshots from the screen. The first is by going through the entire user scenario up to the desired screen. The second is when we do not launch the entire application, but only start individual fragments – this allows you to take screenshots quickly and stably. You can read more about this Here. In addition to the screenshots themselves, xml files will be saved indicating all the lines on the screen and their id.

6. Working with logcat

There are tests that do not have enough interaction with the UI, because some of the logic may be hidden from the user, and to check that our application works as we expect it to, we need to access the logs via logcat. Kaspresso provides us with a ready-made solution here too – to find the line of interest in the log, just do:

device.logcat.readLogcatRows(includePattern = "some string")

7. Steps

Kaspresso makes automated tests more readable by separating pieces of code into separate blocks that correspond to test cases, and also adds logging and screenshots to tests. You can read more about steps here Here.

8. Flak protection

I already mentioned autoscroll above, but that's not all that Kaspresso provides to improve test stability: for example, it can close system windows, wait for asynchronous elements to load, and this can be easily and flexibly configured independently.

All this saves many hours on searching and implementing the necessary functionality. And for this I had to invent my own “bicycles”, but the same time could have been spent on writing new autotests.

I would also like to talk a little about a perhaps unobvious advantage of native tools: tests are in the same project as the app being tested. This expands our capabilities, allowing us to test the app as a white box, which adds stability to tests and expands capabilities.

It turns out that Kaspresso…

This is a framework that anyone can use to start writing automated tests for Android apps, as the entry threshold is very low. My stereotypes about native automation tools were destroyed, as most of them were related to Espresso. Kaspresso can cover all the needs for testing Android apps.

If Kaspresso is compared to Appium, then in its capabilities it is not only not inferior to Appium, but also surpasses it in many ways! Therefore, if you also want to try new tools and destroy stereotypes about testing and more – Join Kaspersky Lab“! And to learn more about working with Kaspresso, join our support chat. This is a large community with more than a thousand members, where there is all the most useful information on working with the framework.