Espresso is an open-source test framework developed by Google. It enables you to perform complex user interface tests on a real device or emulator.
However, in our rapidly changing world with numerous complex frameworks, libraries and growing teams, relying solely on Espresso for test development can cause problems. It may start to slow down your team’s work, increase time-to-market metrics, and make it harder to onboard new employees due to the lack of clarity in your test process.
Some of these problems include:
Lack of readable logs
Espresso logs contain almost no useful information about what happened in a test. To save time, you need more readable logs that will help you solve actual problems, not just issues related to Espresso.
Flaky tests
When it comes to UI-test frameworks, flakiness can be one of the most frustrating issues to deal with. This is not just a problem with Espresso — its a common challenge across other frameworks, too. Flakiness can show up in different ways, like tests that occasionally fail, tests that fail on certain devices, or tests that fail without a clear reason. In addition to being a headache for developers, flakiness can also have a significant impact on the overall quality of the application. For example, it can lead to false positives or negatives, which can make developers end up wasting time and resources when trying to find the main problem.
No test report integrations
Gradle provides a default report for Espresso tests out of the box. However, this report is not very informative and cannot be customized. While it does indicate which tests have failed, it is not always clear at which stage or for what reason.
No Screenshot tests
Espresso does not have an in-built screenshot function. If you are developing an application that will be available globally, you will need to localize it into different languages. When localizing the UI, it is important for the translator to see the context of a word or phrase, including the specific screen it appears on. Also, if you need some sort of design review, Espresso doesn’t provide any screenshot feature to resolve an issue.
Test readability issues
The readability of tests can suffer when developing with Espresso, and this problem is becoming more widespread with the expansion of the code base. Also, Espresso is not a declarative framework, unlike other popular solutions nowadays.
Here’s an example:
Kaspresso
To solve these issues we’re offering the open-source Kaspresso framework that is based on Espresso and UI Automator. Read more about the interceptors below.
We provide many behavior and watcher interceptors to resolve problems and improve the performance and stability of automated testing.
Kaspresso Behaviour interceptors intercept any calls from the inner app via ViewInteraction, DataInteraction, WebView actions via WebInteraction, and outer app actions via UiObjectInteraction, UiDeviceInteraction. They can also perform specific actions.
Likewise, Watcher interceptors intercept calls to ViewAction, ViewAssertion, Atom, WebAssertion, UiObjectAssertion, UiObjectAction, UiDeviceAssertion, and UiDeviceAction to perform certain actions.
These interceptors are not based on any library. Here is a brief description:
- StepWatcherInterceptors — an interceptor for Step lifecycle actions
- TestRunWatcherInterceptors — an interceptor for the entire Test lifecycle action
Please remember! By default, Behavior and Watcher interceptors work under the hood in every action and assertion of every View of Kakao and Kautomator in Kaspresso.
Writing readable logs
Kaspresso writes its own logs, which are detailed and easy to read with the help of LogginStepWatcherInterceptor and plenty of other loggin interceptors. Also, you can use an abstraction called “Step”, which can provide detailed logs, screenshots, and a lot of other artifacts after a test run.
100% stability, no flakiness.
To eliminate instability in tests, Kaspresso uses several Behavior interceptors:
- The FlakySafety interceptor wraps up all actions and assertions from Kakao/Automator, attempting to repeat the action if any error occurs.
- In order to avoid exceptions, Kaspresso will attempt to automatically execute a scroll to your View if it is not visible via AutoScroll interceptor.
- If it prevents the test from successfully executing, the SystemSafety interceptor tries to dismiss all system and permission dialogs.
Allure Support
Allure is an open-source framework that is designed to create beautiful, interactive, and easy-to-read reports for automated tests. It allows developers and testers to create detailed and meaningful reports of their test results and can be integrated with various test frameworks such as JUnit, TestNG, and more.
Starting with version 1.3.0, Kaspresso can create test reports with Allure and several new interceptor features:
- VideoRecordingInterceptor — a video recording interceptor
- In case a test fails, the DumpViewsInterceptor dumps an XML representation of the View hierarchy
Screenshots
Any screen can be easily captured with Kaspresso. Even with legacy screens and when nothing needs to be refactored or mocked.
Use the DocLocScreenshotTestCase class and extend it in your test case to construct a screenshot test, as illustrated below:
The base constructor accepts only one parameter: locales — a comma-separated list of locales to use when running the test. The directory “/sdcard/Documents/screenshots/” in the device’s storage will allow you to access screenshots that have been captured.
Kaspresso Builder presets
Kaspresso has various builder presets that include a base set of interceptors, allowing you to start developing faster without worrying about the base configuration.
- Simple (preconfigured with logging and flaky-safe features) [Builder] for test environment configuration.
If you desire to override some variables in Configurator please use [customize] parameter here.
The example is:
In this case your implementation of adbServer will be used for initializing of all other variables. So, your implementation has a priority over the default implementation while using [customize] parameter for the overriding. Otherwise, if you don’t set custom implementation then default implementation of adbServer will be explored
2. Advanced (full-featured with screenshot functionality) [Builder] for test environment configuration.
Here’s example:
In this case your implementation of adbServer will be used for initializing of all other variables. So, your implementation has a priority over the default implementation while using [customize] parameter for the overriding. Otherwise, if you don’t set custom implementation then default implementation of adbServer will be explored.
Controlling Interceptors
Kaspresso has interceptors turned on by default, including the Watcher, Behavior, Kaspresso and BuildStepReport interceptors.
Kaspresso can be set up to use pre-existing interceptors with various parameter settings or with custom interceptors that meet the requirements of your test.
For example, if your test requires that only FlakyInterceptor be used:
You can follow these steps (using ViewAction as an example) if you wish to build a custom interceptor from scratch:
And then in your test:
With the release of Kaspresso 1.5.3 we significantly improved our interceptor APIs, fixed several bugs, and wrote plenty of tests for Android API 21, 30, 33 to ensure that the interceptors function. This is a great time to try it!
Custom Kakao clicks
Kaspresso has the option to override Espresso custom clicks. Kakao library provides a set of prepared custom clicks, which improves testing stability — especially on devices under high load.
All details about the problem and solutions are described in the Kakao documentation.
An example of how to apply custom clicks in your test is presented in ClickTest.
As you can see, all of the problems with Espresso are solved by Kaspresso:
- Makes tests easier to read
- No flakiness
- Improved logs
- Integrates test reporting with Allure
- Simple screenshot tests
If the Kaspresso framework sounds good to you, you can explore it on github and give us a star. We have a discord channel if you need any help. And you can also check out our most recent tutorial.
Furthermore, we welcome you to read our previous publications about autotests on Android:
