Forem: Kaspresso

How to make Espresso tests more readable and stable

Kaspresso — Wed, 03 Apr 2024 12:50:43 +0000

If you have ever written tests on Espresso, the open-source testing framework from Google, you know that they are not always stable and easy to read. My name is Ksenia Nikitina, and I am an Android developer at Kaspersky. In this article, I will provide you with a way to make your autotests meet all the key qualities, including high readability, stability, logability, possibility of taking screenshots, compatibility with AndroidOS, and, finally, a well-thought-out and intuitive architecture.

So, when there is a need to write autotests on Android, we most often turn to the Espresso framework by Google (if you are not familiar with Espresso, you can find out more about it in the official documentation). Espresso allows you to work with application elements natively and using the white-box method. You can first find the necessary elements on the screen using matchers, and then perform various actions or tests on them.

Let's look at how the autotests work using a specific example. You can launch the application and reproduce all the steps described below by yourself by downloading the source code on our GitHub and launching the Tutorial project.

When we open the application, we see a screen with the "Internet Availability" button, and when we click on it, we navigate to the Wifi status check screen.

The "Check Wifi status" button is clickable. Once clicked, the current Wifi status is displayed.

It is also important to us that when we rotate the screen, the text indicating the Wifi status does not change.

To sum it up, to verify that the application works correctly, we need to go through the following steps:
Before starting the test, set the device to landscape mode, turn on Wifi, and launch the main screen of the application.
Check that the Internet Availability button is visible and clickable.
Check that the header indicating the Wifi status does not contain any text.
Click the "Check Wifi status" button.
Check that the header text changed to "enabled".
Disable Wifi.
Click the "Check Wifi status" button.
Check that the header text changed to "disabled".
Flip the device.
Check that the header text is still "disabled".

Let's try to automate this text test case and use it as an example to discuss the existing shortcomings of Espresso.

Espresso test example

Our test class using the Espresso framework:



package com.kaspersky.kaspresso.tutorial 

import androidx.test.espresso.Espresso.onView 
import androidx.test.espresso.action.ViewActions 
import androidx.test.espresso.assertion.ViewAssertions.matches 
import androidx.test.espresso.matcher.ViewMatchers.isClickable 
import androidx.test.espresso.matcher.ViewMatchers.isDisplayed 
import androidx.test.espresso.matcher.ViewMatchers.withId 
import androidx.test.espresso.matcher.ViewMatchers.withText 
import androidx.test.ext.junit.rules.activityScenarioRule 
import androidx.test.ext.junit.runners.AndroidJUnit4 
import androidx.test.platform.app.InstrumentationRegistry 
import org.junit.Rule 
import org.junit.Test 
import org.junit.runner.RunWith 

@RunWith(AndroidJUnit4::class) 
class WifiSampleEspressoTest { 

    @get:Rule 
    val activityRule = activityScenarioRule<MainActivity>() 

    @Test 
    fun test() { 
        // launch target screen 
        onView(withId(R.id.wifi_activity_btn)).check(matches(isDisplayed())) 
        onView(withId(R.id.wifi_activity_btn)).check(matches(isClickable())) 
        onView(withId(R.id.wifi_activity_btn)).perform(ViewActions.click()) 
        // set portrait orientation 
        val uiAutomation = InstrumentationRegistry.getInstrumentation().uiAutomation 
        uiAutomation.executeShellCommand(SHELL_COMMAND_AUTO_ROTATE_DISABLE) 
        uiAutomation.executeShellCommand(SHELL_COMMAND_PORTRAIT_ORIENTATION) 

        // test 
        onView(withId(R.id.wifi_status)).check(matches(withText(""))) 
        onView(withId(R.id.check_wifi_btn)).check(matches(isDisplayed())) 
        onView(withId(R.id.check_wifi_btn)).check(matches(isClickable())) 
        onView(withId(R.id.check_wifi_btn)).perform(ViewActions.click()) 
        onView(withId(R.id.wifi_status)).check(matches(withText(R.string.enabled_status))) 

        // Turning off wifi 
        uiAutomation.executeShellCommand(SHELL_COMMAND_TURN_OFF_WIFI) 

        // wait for switching wifi 
        Thread.sleep(3000) 

        // test 
        onView(withId(R.id.check_wifi_btn)).perform(ViewActions.click()) 
        onView(withId(R.id.wifi_status)).check(matches(withText(R.string.disabled_status))) 

        //rotate 
        uiAutomation.executeShellCommand(SHELL_COMMAND_AUTO_ROTATE_DISABLE) 
        uiAutomation.executeShellCommand(SHELL_COMMAND_LANDSCAPE_ORIENTATION) 

        // wait for rotation 
        Thread.sleep(3000) 

        // test 
        onView(withId(R.id.wifi_status)).check(matches(withText(R.string.disabled_status))) 
    } 

    private companion object { 

        const val SHELL_COMMAND_AUTO_ROTATE_DISABLE = "content insert --uri content://settings/system --bind name:s:accelerometer_rotation --bind value:i:0" 
        const val SHELL_COMMAND_PORTRAIT_ORIENTATION = "content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:0" 
        const val SHELL_COMMAND_LANDSCAPE_ORIENTATION = "content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:1" 
        const val SHELL_COMMAND_TURN_OFF_WIFI = "svc wifi disable" 
    } 
} 


```Kotlin

In this example, we realized that it was impossible to implement the test using Espresso alone, so we had to bring in the UIAutomator library. The test runs and allows you to check if the application is working correctly, but, unfortunately, the code has several drawbacks at the moment.

What we would like to improve in the code: separate the logic of element descriptions and the sequence of actions and checks; use a declarative style of writing tests; eliminate multiple repetitive onView calls and hierarchical nesting. Unfortunately, it is impossible to cover all the needs for Android autotesting with Espresso alone due to the lack of certain features.

## Code improvement
Let's try rewriting the code of our test by resorting to the open-source framework [Kaspresso](https://kas.pr/medium-nikitina-kaspresso-espressotests-kaspresso), which takes a declarative approach to writing tests. Let's look at a specific section of the code.

It looked like this:

onView(withId(R.id.wifi_activity_btn)).check(matches(isDisplayed()))
onView(withId(R.id.wifi_activity_btn)).check(matches(isClickable()))
onView(withId(R.id.wifi_activity_btn)).perform(ViewActions.click())


And now it turns out like this:

wifiActivityButton {

isVisible()

isClickable()

click()

}


Kaspresso uses [Kakao](https://github.com/KakaoCup/Kakao), a Kotlin-DSL wrapper for Espresso. The Kaspresso open-source framework inherited two main concepts from Kakao. The first is KView - a special representation of the UI elements that the test interacts with. Using KView saves us from constantly calling the onView method; now we just need to add matchers in the KView constructor once.

The second concept is the Screen class (implementation of the [Page Object](https://kasperskylab.github.io/Kaspresso/en/Wiki/Page_object_in_Kaspresso/) pattern), which describes all the elements that the test interacts with. The concept comes from web development and is about creating a description of the screen visible to the user. This object does not contain any logic. This allows you to describe Screens and their elements in a separate file and interact with them from the test class code in a declarative style. Thus, Page Objects are completely independent, which makes them reusable to the max.

Let's rewrite our test class using the Kaspresso framework. If you run into problems with any of the following steps, you can find a ready-made version of the autotest in the [tutorial_results](https://github.com/KasperskyLab/Kaspresso/tree/TECH-tutorial-results) branch.

The first step is to create the MainScreen Page Object:

package com.kaspersky.kaspresso.tutorial.screen

import com.kaspersky.kaspresso.screens.KScreen
import com.kaspersky.kaspresso.tutorial.R
import io.github.kakaocup.kakao.text.KButton

object MainScreen : KScreen() {

override val layoutId: Int? = null 
override val viewClass: Class<*>? = null 

val wifiActivityButton = KButton { withId(R.id.wifi_activity_btn) }

}


Here we need to determine the ID of the layout installed on the screen (layoutId) and the name of the class (viewClass). This is required to link the test to a specific layout file and the activity or fragment class. Linking them makes the tasks of further support and development of the test more convenient, but for now, we are faced with the task of considering a demo test class, so let's leave the value at "null".

Next, let's create a WifiScreen:

package com.kaspersky.kaspresso.tutorial.screen

import com.kaspersky.kaspresso.screens.KScreen

import com.kaspersky.kaspresso.tutorial.R

import io.github.kakaocup.kakao.text.KButton

import io.github.kakaocup.kakao.text.KTextView

object WifiScreen : KScreen() {

override val layoutId: Int? = null  

override val viewClass: Class<*>? = null  

val checkWifiButton = KButton { withId(R.id.check_wifi_btn) }  
val wifiStatus = KTextView { withId(R.id.wifi_status) }

}


Now let's get down to the test cases. The test class should be inherited from the TestCase class. Let's create such a WifiSampleTest class and add a method annotated with a @Test (import org.junit.Test) to check how the application works.

package com.kaspersky.kaspresso.tutorial

import androidx.test.ext.junit.rules.activityScenarioRule
import com.kaspersky.kaspresso.device.exploit.Exploit
import com.kaspersky.kaspresso.testcases.api.testcase.TestCase
import com.kaspersky.kaspresso.tutorial.screen.MainScreen
import com.kaspersky.kaspresso.tutorial.screen.WifiScreen
import org.junit.Rule
import org.junit.Test

class WifiSampleTest : TestCase() {

@get:Rule 
val activityRule = activityScenarioRule<MainActivity>() 

@Test 
fun test() { 
    MainScreen { 
        wifiActivityButton { 
            isVisible() 
            isClickable() 
            click() 
        } 
    } 
    WifiScreen {         
        device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait) 
        wifiStatus.hasEmptyText() 
        checkWifiButton { 
            isVisible() 
            isClickable() 
            click() 
        } 
        wifiStatus.hasText(R.string.enabled_status) 
        device.network.toggleWiFi(false) 
        checkWifiButton.click() 
        wifiStatus.hasText(R.string.disabled_status) 
        device.exploit.rotate() 
        wifiStatus.hasText(R.string.disabled_status) 
    } 
}

}


We mentioned earlier that Espresso doesn't work with Android OS, so users have to resort to the UIAutomator library. Note that the test code uses an instance of the Device class, which is part of the Kaspresso framework. This object has many useful methods suitable for interacting with Android OS. You can read more about them [here](https://kasperskylab.github.io/Kaspresso/Wiki/Working_with_Android_OS/).

What did we achieve?

1. Screen descriptions and testing the logic of their work are now separated. Test cases can now be described independently of Screens, and Screen classes can be reused in different tests.
2. The code has become much more readable, and it is now possible to write tests in a declarative style. We simply indicate, what actions and checks we want to perform and on which Screen.

## Code separation according to the steps of the test cases
The test class code is already looking better, but it still has some issues. Usually, any tests (including manual ones) are performed according to test cases. That is, the tester has a sequence of steps that they follow to check the Screen performance Now imagine that our test class contains way more steps and, accordingly, lines of code. Because it is unclear where one step ends and another one begins, it gets extremely difficult to understand and expand. We can mitigate this problem by using comments. Let's add comments to each step in our test class:

package com.kaspersky.kaspresso.tutorial

class WifiSampleWithStepsTest : TestCase() {

@get:Rule 
val activityRule = activityScenarioRule<MainActivity>() 

@Test 
fun test() { 
    // Step 1. Open target screen 
    MainScreen { 
        wifiActivityButton { 
            isVisible() 
            isClickable() 
            click() 
        } 
    } 
    WifiScreen { 
        // Step 2. Check correct wifi status 
        device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait) 
        wifiStatus.hasEmptyText() 
        checkWifiButton { 
            isVisible() 
            isClickable() 
            click() 
        } 
        wifiStatus.hasText(R.string.enabled_status) 
        device.network.toggleWiFi(false) 
        checkWifiButton.click() 
        wifiStatus.hasText(R.string.disabled_status) 

        // Step 3. Rotate device and check wifi status 
        device.exploit.rotate() 
        wifiStatus.hasText(R.string.disabled_status) 
    } 
}

}


This slightly improves the readability of the code, but it won't solve all the issues. For example, if one of the tests fails, how do we know at which step it happened? Espresso in this case just dumps it into the log, so you have to examine the data, trying to figure out what went wrong. It would be much better if the logs displayed information about the start and end of each step.
We can also wrap some parts of the code in "try/catch" blocks to catch test failures. Now our test looks like this:

package com.kaspersky.kaspresso.tutorial

import android.util.Log
import androidx.test.core.app.takeScreenshot
import androidx.test.ext.junit.rules.activityScenarioRule
import com.kaspersky.kaspresso.device.exploit.Exploit
import com.kaspersky.kaspresso.testcases.api.testcase.TestCase
import com.kaspersky.kaspresso.tutorial.screen.MainScreen
import com.kaspersky.kaspresso.tutorial.screen.WifiScreen
import org.junit.Rule
import org.junit.Test

class WifiSampleWithStepsTest : TestCase() {

@get:Rule 
val activityRule = activityScenarioRule<MainActivity>() 

@Test 
fun test() { 
    try { 
        Log.i("KASPRESSO", "Step 1. Open target screen -> started") 
        MainScreen { 
            wifiActivityButton { 
                isVisible() 
                isClickable() 
                click() 
            } 
        } 
        Log.i("KASPRESSO", "Step 1. Open target screen -> succeed") 
    } catch (e: Throwable) { 
        Log.i("KASPRESSO", "Step 1. Open target screen -> failed") 
        takeScreenshot() 
    } 
    WifiScreen { 
        try { 
            Log.i("KASPRESSO", "Step 2. Check correct wifi status -> started") 
            device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait) 
            wifiStatus.hasEmptyText() 
            checkWifiButton { 
                isVisible() 
                isClickable() 
                click() 
            } 
            wifiStatus.hasText(R.string.enabled_status) 
            device.network.toggleWiFi(false) 
            checkWifiButton.click() 
            wifiStatus.hasText(R.string.disabled_status) 
            Log.i("KASPRESSO", "Step 2. Check correct wifi status -> succeed") 
        } catch (e: Throwable) { 
            Log.i("KASPRESSO", "Step 2. Check correct wifi status -> failed") 
        } 

        try { 
            Log.i("KASPRESSO", "Step 3. Rotate device and check wifi status -> started") 
            device.exploit.rotate() 
            wifiStatus.hasText(R.string.disabled_status) 
            Log.i("KASPRESSO", "Step 3. Rotate device and check wifi status -> succeed") 
        } catch (e: Throwable) { 
            Log.i("KASPRESSO", "Step 3. Rotate device and check wifi status -> failed") 
            takeScreenshot() 
        } 
    } 
}

}


In some catch blocks, we take screenshots that can help us analyze fails in the future. One way to take a screenshot is to call the takeScreenshot() method, but it is not recommended to use it directly. You can get acquainted with a more convenient and flexible tool for taking screenshots in Kaspresso [in this lesson](https://kasperskylab.github.io/Kaspresso/en/Tutorial/Logger_and_screenshot/).

The open-source Kaspresso framework offers Step, a useful and convenient abstraction. Everything that we have just written manually is implemented inside of it.

To use Steps, you need to call the run {} method and list in curly brackets all the steps that are to be run during the test. Each step should be called inside a Step block. The test code then looks like this:

package com.kaspersky.kaspresso.tutorial

class WifiSampleWithStepsTest : TestCase() {

@get:Rule 
val activityRule = activityScenarioRule<MainActivity>() 

@Test 
fun test() { 
    run { 
        step("Open target screen") { 
            MainScreen { 
                wifiActivityButton { 
                    isVisible() 
                    isClickable() 
                    click() 
                } 
            } 
        } 
        step("Check correct wifi status") { 
            WifiScreen { 
                device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait) 
                wifiStatus.hasEmptyText() 
                checkWifiButton { 
                    isVisible() 
                    isClickable() 
                    click() 
                } 
                wifiStatus.hasText(R.string.enabled_status) 
                device.network.toggleWiFi(false) 
                checkWifiButton.click() 
                wifiStatus.hasText(R.string.disabled_status) 
            } 
        } 
        step("Rotate device and check wifi status") { 
            WifiScreen { 
                device.exploit.rotate() 
                wifiStatus.hasText(R.string.disabled_status) 
            } 
        } 
    } 
}

}


Let's take a look at the logs. There we see both logs of specific actions and checks performed during the test, as well as meta-information about the steps - name, calling class, completion time, success message, or error log if the test failed.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xugk7awz232w3sbwzy7t.png)


Any user of the Kaspresso framework can add the necessary improvements to the functionality of the Steps: recording steps in the allure report, screenshots taken at the moment of step failure, view hierarchy output, and much more. To do this, the user needs to write their [own interceptor](https://kasperskylab.github.io/Kaspresso/en/Wiki/Kautomator-wrapper_over_UI_Automator/#interceptor-) or use a ready-made one.

Let's run the test again with the internet turned off:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eqlr6xxf5a05cjgs49gx.png)

## Sections - preparing states before and after the test

Great, but there's something else to take into account. Often, when we compile tests, we have to consider the necessity of checking the application performance under certain preconditions. So in our test, we need the device to be in the default state before each launch, and to return to the same state after the test is completed.

To do this, there are before and after blocks in Kaspresso. The code inside the before block is run before the test - we can set the default settings here. During the test, the phone state may change: we can turn off the internet or change the orientation mode, but after the test, we need it to return to its original state. And that's where the after block comes in.

Let's improve our test class by using sections. Before starting the test in the before section, let's set the landscape mode and turn the Wifi on:

device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait)
device.network.toggleWiFi(true)


The before and after blocks help not only to visually separate the setup of the desired state into separate blocks but also to guarantee the completion of these blocks. If we look at the test that we wrote at the beginning of this article using Espresso, we can see that the same actions were recorded as steps, and if the test fails abruptly, the default settings may not be restored. Using before and after sections ensures that these blocks are run at the proper time.

Also note that now, after flipping the device, we check if the text remains the same, but not if the orientation mode has actually changed. It appears that if the device.exploit.rotate() method did not work for some reason, the orientation mode does not change and there is no point checking the text. Let's add a check to verify whether the orientation mode of the device has changed to landscape.

Assert.assertTrue(device.context.resources.configuration.orientation == Configuration.ORIENTATION_LANDSCAPE)


Now the full test code looks like this:

package com.kaspersky.kaspresso.tutorial

import android.content.res.Configuration
import androidx.test.ext.junit.rules.activityScenarioRule
import com.kaspersky.kaspresso.device.exploit.Exploit
import com.kaspersky.kaspresso.testcases.api.testcase.TestCase
import com.kaspersky.kaspresso.tutorial.screen.MainScreen
import com.kaspersky.kaspresso.tutorial.screen.WifiScreen
import org.junit.Assert
import org.junit.Rule
import org.junit.Test

class WifiSampleWithStepsTest : TestCase() {

@get:Rule 
val activityRule = activityScenarioRule<MainActivity>() 

@Test 
fun test() { 
    before { 
        device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait) 
        device.network.toggleWiFi(true) 
    }.after { 
        device.exploit.setOrientation(Exploit.DeviceOrientation.Portrait) 
        device.network.toggleWiFi(true) 
    }.run { 
        step("Open target screen") { 
            MainScreen { 
                wifiActivityButton { 
                    isVisible() 
                    isClickable() 
                    click() 
                } 
            } 
        } 
        step("Check correct wifi status") { 
            WifiScreen { 
                wifiStatus.hasEmptyText() 
                checkWifiButton { 
                    isVisible() 
                    isClickable() 
                    click() 
                } 
                wifiStatus.hasText(R.string.enabled_status) 
                device.network.toggleWiFi(false) 
                checkWifiButton.click() 
                wifiStatus.hasText(R.string.disabled_status) 
            } 
        } 
        step("Rotate device and check wifi status") { 
            WifiScreen { 
                device.exploit.rotate() 
                Assert.assertTrue(device.context.resources.configuration.orientation == Configuration.ORIENTATION_LANDSCAPE) 
                wifiStatus.hasText(R.string.disabled_status) 
            } 
        } 
    } 
}

}


## Conclusion and useful references
So, let's summarize. The open-source Kaspresso framework allows you to make test code readable due to a declarative approach using Kotlin DSL and an "out-of-the-box" implemented Page Object pattern, and it also allows you to make it stable due to internal improvements and interceptors. Here are some advantages of Kaspresso, highlighted by us using a specific example:

1. Good readability. You no longer need to use long constructs with matchers to search for elements on the screen for interaction from the test, and all the UI elements that your test interacts with can be described in one place (in a specific Screen object).
2. Logging. Kaspresso provides detailed and intuitive logs indicating the current step. You don't need to add them manually, because everything is implemented internally. If necessary, you can change and supplement the logs as you wish.
3. Code architecture. Using the Page Object pattern implementation described above, you can make your code in test files more readable, maintainable, reusable, and intuitive. Kaspresso also provides various methods and abstractions to improve the architecture (such as Steps, before and after sections, and more).
4. Low entry threshold for mastering the framework. No programming language knowledge is required to write autotests; all you need to do is use the declarative approach.

If this article was useful to you and you plan to use Kaspresso in your projects, join the [Kaspresso community on Discord](https://kas.pr/medium-nikitina-kaspresso-espressotests-discord). We will try to provide you with all the necessary support and announce the following articles from the current series of materials about Kaspresso. 
 
You can also take the [Tutorial](https://kas.pr/medium-nikitina-kaspresso-espressotests-tutorial) prepared by the Kaspresso team to familiarize yourself with other features of the framework and visit the [Wiki section](https://kasperskylab.github.io/Kaspresso/en/Wiki/). We hope to see you among our contributors soon! 
 
Furthermore, we welcome you to read our previous publications about autotests on Android: 
 
[A step-by-step tutorial in codelab format for Android UI testing ](https://medium.com/kasperskymedia/a-step-by-step-tutorial-in-codelab-format-for-android-ui-testing-a5581f251b29)
 
And don't forget to [give us a star on Github](https://kas.pr/medium-nikitina-kaspresso-espressotests-klgithub) ;)

A step-by-step tutorial in codelab format for Android UI testing

Kaspresso — Fri, 16 Feb 2024 09:20:54 +0000

Hi everyone! My name is Azamat Cherchesov and I am a senior Android developer at Kaspersky. We have been developing mobile applications for more than 10 years and know from our own experience that testing is an important stage in the entire process of creating new apps and preparing each new release. For Android applications Espresso is the default recommended framework, but it contains several known problems that do not allow us to cover all our needs for auto testing.

What do we want?

Readability

Espresso has some problems with readability. Its syntax is built on a hierarchical system of matchers, with a sufficiently high level of nesting, making the code hard to read and maintain.

@Test
fun espressoTest() {
  onView(withId(R.id.toFirstFeature))
    .check(ViewAssertions.matches(
     ViewMatchers.withEffectiveVisibility(
       ViewMatches.Visibility.VISIBLE)))
  onView(withId(R.id.toFirstFeature))
    .check(ViewAssertions.matches(ViewMatchers.isClickable()))
  onView(withId(R.id.toFirstFeature)).perform(ViewActions.click())
}

The above is the simplest example, but even this shows a readability problem.

For contrast, here’s an example of how this code could look differently:

@Test
fun readableTest() {
  MainScreen {
    firstFeatureButton {
      isVisible()
      isClickable()
      click()
    }
  }
}

We would also like to have a declarative approach when writing autotests, which is also not possible with Espresso.

Stability

Espresso does not work well with UI elements that are not displayed immediately. You can try idling resources, but it is difficult to implement. Espresso tests are not stable — if you run a simple test several times it can fail once or twice for some unpredictable reason (a common problem for most testing frameworks). You can read more about unstable clicks in Espresso and how we improved it on our website.

Detailed and easy-to-read logs and reports

After testing, there is no logged sequence of actions that were successfully completed. In case of a fail, it can be difficult to understand at what step in a particular test script something went wrong — Espresso simply provides a long trace with an error.

Executing ADB commands

Sometimes the default Android instrumental test tooling is not enough: a test case could imply that the device’s internet connection is off, brightness is set to a certain level, network is slow etc. Most of these conditions could be easily set beforehand on the CI side, but what if you want to turn off the internet during the test? Chances are you would need to fall back to manual testing. Here are some reasons why ADB may be needed in Android tests. In order to:

perform standard operations like push/pull, manipulate files, install additional APKs, uninstall unwanted, etc.
emulate anything using ADB emu: call simulation, fingerprint interaction, slow internet simulation, set a fake geolocation, etc.

Interaction with other applications and system elements and interfaces

You won’t even be able to interact with the system dialog using Espresso. Also you may need to perform some actions in another application during the test.

Google recommends using UiAutomator, but its syntax is also not very readable and it is also different from Espresso. In addition, we would like to see much more stability and speed of operation.

Screenshots

Mobile applications are often localized into multiple languages. Screenshot testing helps technical writers and localization engineers to better understand in what context new strings will be used and ensure they are suitable for the context and aren’t too long. It also helps with design testing — you can take real screens and compare them with mockups. We also want to see screenshots after running e2e tests (this can be useful when running tests using continuous integration to generate detailed reports).

You may know some screenshot frameworks, but in addition to the native approach to writing screenshot tests, we would like to be able to take screenshots of the application in different states, including negative scenarios (internet lost, server returned an error, record not found in the database, subscription or license expired). To do this, we need an easy way to transfer the application (or some screens) to the required state directly from the test screenshot code without unnecessary external manipulations.

Kaspresso comes to the rescue

As a result of much research and searching for best practices and solutions, the open source framework Kaspresso was created to cover all the needs for testing Android apps and has become a mature solution with a large team and an interested community. Take a look at some features Kaspresso can offer you:

Built-in protection against flaky tests
Page object pattern out of the box
Declarative approach for writing tests
Ability to interact with other applications and system elements and interfaces
Human readability with Kotlin DSL wrappers over UiAutomator and Espresso
Detailed logs and reports (logs, view hierarchy, screenshots, video etc.)
ADB support
Screenshot testing with native approach (with dark mode support)
Compose support
Allure support
Robolectric support
Easy migration from Espresso
Flexible configuration options
Automatic artifact pulling after test execution

You can find detailed information on our website in the Home and Wiki tabs.

A little dive into the details

Protection against flaky tests

Kaspresso provides interceptors and wrappers over Espresso and UiAutomator that catch exceptions in test code execution and retries with some additional logic.

In a nutshell, interceptors wrap calls to check and perform methods.

Beyond simple retries, Kaspresso intercepts, and deals with, cases when scroll is needed or some elements are not visible due to system dialogs or long content loading.

We recommend you try it now or learn more about it here.

Interaction with Android OS

Kaspresso provides the Facade class Device. With this class you can:

push/pull files
enable/disable network
give permissions like a user
emulate phone calls and fake geolocations
take screenshots
enable/disable GPS
rotate device or press system buttons
enable/disable accessibility
change app language
collect and parse logcat output

(see more about the Device class here).

Readability

First of all, let’s have a look at how beautiful, readable and concise Kaspresso tests are!

@Test
fun readableTest() {
  MainScreen {
    firstFeatureButton {
      isVisible()
      isClickable()
      click()
    }
  }
}

Under the hood, Kaspresso uses Kakao, — a Kotlin DSL wrapper over Espresso. From Kakao our framework inherited two main concepts.

The first is KView, a special representation of the interface element with which interaction will occur in the test. Using KView saves us from constantly calling the onView method; now we just need to put matchers in the KView constructor once.

object MainScreen: Screen<MainScreen> {
   val firstFeatureButton = KButton{ withId(R.id.toFirstFeature) }
}

The second concept is the Screen class (an implementation of the page object pattern), which describes all the elements that will be interacted with during the test. The concept comes from web development and is about creating a description of the screen that is visible to the user. This object does not contain any logic, which allows you to describe screens and their elements in a separate file and interact with them from the test class code. Thus, page objects are completely independent, thereby achieving maximum reusability.

Kotlin DSL over Espresso and UiAutomator provides a declarative approach for writing tests. Tests archives human readability and becomes easier for the next support and extensions.

Ability to execute ADB commands

Espresso, unlike Appium, does not allow you to execute ADB commands. However, with Kaspresso you have the opportunity not only to execute ADB commands in native tests, but to do it directly from the test code. The implementation is not that simple. As I go into more detail in this article, I will make it more complex. See this article for details of how this became possible.

Screenshots

Kaspresso is not the first or only framework that allows you to create screenshot tests. But unlike other tools, our framework provides several killer screenshot features.

Firstly, as we mentioned earlier, we want to be able to test (including screenshot tests) the application not only in positive, but also in negative scenarios (internet lost, server returned an error, record not found in the database, subscription or license expired). Because Kaspresso is a native framework, we can emulate any state inside the tests. Besides, having implemented Screen classes in regular E2e tests, you can reuse them and write screenshot tests very quickly.

Secondly, Kaspresso allows you not only to set all the states by emulating various scenarios, but to do it directly without even having to launch the application! You can simply take the required Activity or Fragment and put it into the special holder.

private lateinit var scenario: 
FragmentScenario<ScreenshotSampleFragment>

@ScreenShooterTest
@Test
fun test() = before {
  scenario = launchFragmentInContainer()
}.after {
}.run {
  scenario.onFragment {
    val view = getUiSafeProxy(it as ScreenshotSampleView)

    view.setNoInternetState()
    captureScreenshot("No Internet state")

    view.setContentLoadingState()
    captureScreenshot("Content is loading state")

    view.setServerErrorState()
    captureScreenshot("Server error state")
  }
}

For more details, have a look at this sample.

Thirdly, Kaspresso allows you to change languages both at the system level and at the application level (by changing string resources in the application). This gives you more options and allows you to run tests faster

Finally, Kaspresso provides the captureFullWindowScreenshot method for screenshotting long screens without having to scroll, as well as the DocLocScreenshotTestCase base class, which you can extend for writing screenshots tests.

Detailed and understandable logs and reports

Thanks to internal interceptors, Kaspresso wraps the test code, adding detailed logs indicating each step with screenshots. After running the tests, various artifacts are available (logs, screenshots, hierarchy of graphic elements, on-screen string identifiers, and much more, which can be downloaded automatically at the end of the run). For visual clarity, here is an example log:

Try the open source framework Kaspresso now with our step-by-step tutorial in codelab format

We recently published 14 lessons about Kaspresso to help you understand better and get real practice. All the lessons are based on the real and ready application, which you can run on your device or emulator (you need to download the source code from our GitHub and run the Tutorial project). If you experience problems during any lesson, you can switch to the TECH-tutorial-results branch and see the final implementation of all tutorial tests.

Tutorial structure

The Tutorial is divided into steps (lessons). Each lesson begins with a brief overview and ends with a summary and conclusions.

How to study this tutorial?

We strive to make the lessons independent from each other, but this is not always possible. For a better understanding of Kaspresso, we recommend starting with the first lesson and moving sequentially to the next. With the codelab format you will combine theory and practice, repeating the instructions from the lessons step by step. In the Kaspresso project, in the tutorial folder, there is an example of the application code for which tests will be written. The first lesson tells you how to download it.

What do you need to know to complete the Tutorial?

We are not trying to teach you autotests from scratch. At the same time, we set no restrictions on knowledge and experience for passing the tutorial, and keep the narrative understandable to autotest and Android beginners. It is almost impossible to talk about Kaspresso without terms from the Java and Kotlin programming languages, the Espresso, Kakao, UiAutomator and other frameworks, the Android operating system and testing itself as an IT area. Nevertheless, the main focus is on explaining Kaspresso itself, and wherever terms are mentioned, we share links to official sources for detailed information and better understanding.

Feedback

If you find any typos, errors or inaccuracies in the materials, want to suggest an improvement or add new lessons to the Tutorial, you can create an Issue in the Kaspresso project or open a Pull request (materials from the Tutorial are in the public domain in the docs folder).

If the Tutorial did not answer your question, you can search the Wiki section or Kaspresso in articles and Kaspresso in video.

You can also join our Discord channel and ask questions there.

I’m not saying goodbye

As you can see, Kaspresso has a lot of very useful functionality that will help simplify your test-writing process. The structured step-by-step tutorial in codelab format lets you not only study this framework, but learn how to write autotests in general.

We will publish a series of articles here, so follow our blog.

Detailed info on how to try out Kaspresso is available on our GitHub page and website. Give stars to our project on GitHub and join our Discord community.