Kaspresso: Android UI Tests Without Espresso Pain

Kaspresso is one of those Android testing tools that sounds like another wrapper around Espresso.

And technically, yes, it is built on top of Espresso and UI Automator.

But that is also the point.

Espresso is powerful, but writing real test automation with plain Espresso can get annoying very fast. You end up with long matchers, repeated waits, flaky clicks, weak logs, screenshots bolted on later, and test code that looks like someone lost a fight with onView().

Kaspresso tries to fix that.

It gives you a cleaner Kotlin DSL, better logging, steps, screenshots, flaky-safety mechanisms, device controls, and access to both app UI and system UI. So you still run native Android instrumentation tests, but the test code becomes more readable and more useful for actual QA work.

Not magic. Not a silver bullet. But definitely less painful than raw Espresso.

---

What Kaspresso actually is

Kaspresso is a native Android UI testing framework.

Under the hood it uses:

So you can think of it like this:

Espresso = raw engine
Kakao = nicer syntax for Espresso
UI Automator = system/outside-app control
Kautomator = nicer syntax for UI Automator
Kaspresso = test framework around all of that

That is why Kaspresso feels closer to real QA automation than plain Espresso.

Espresso gives you the tools. Kaspresso gives you a workflow.

---

When I would use Kaspresso

I would use Kaspresso when I test an Android app and I want native UI tests that are readable, stable enough for CI, and not completely horrible to maintain.

Good use cases:

Bad use cases:

Kaspresso is not trying to replace every testing tool.

It is for Android UI/instrumentation tests.

---

Why use Kaspresso instead of plain Espresso?

Plain Espresso works. I am not saying it is bad.

But if you have written enough Espresso tests, you know the usual pain:

• noisy onView(withId(...)) code everywhere
• repeated matchers
• weak reporting
• screenshots are not built into your normal flow
• logs are not friendly for debugging
• flaky waits become your problem
• test readability gets worse as the suite grows

Kaspresso improves the working experience.

Example of Espresso style:

onView(withId(R.id.email))
    .perform(typeText("demo@test.com"), closeSoftKeyboard())

onView(withId(R.id.password))
    .perform(typeText("password"), closeSoftKeyboard())

onView(withId(R.id.loginButton))
    .perform(click())

onView(withId(R.id.homeTitle))
    .check(matches(isDisplayed()))

Same idea with Kaspresso/Kakao screen objects:

LoginScreen {
    email.replaceText("demo@test.com")
    password.replaceText("password")
    loginButton.click()
}

HomeScreen {
    title.isDisplayed()
}

This is not just prettier. It matters when you have 100+ tests and need to understand failures fast.

---

Why use Kaspresso instead of Appium?

Appium is useful when you need cross-platform automation or black-box testing from outside the app.

But for native Android apps, Appium is often heavier than you need.

My practical opinion:

Use Appium if the company wants one automation stack for Android and iOS.

Use Kaspresso if you are serious about Android and want tests that Android developers can also run and debug.

For Android-only UI tests, Kaspresso is usually the more sane choice.

---

Why use Kaspresso instead of Robolectric?

Robolectric is not the same kind of tool.

Robolectric runs Android-ish tests on the JVM. It is fast and useful for testing logic that touches Android classes without launching a real emulator.

Kaspresso runs on a real device or emulator as an instrumentation test.

Use Robolectric for fast feedback.

Use Kaspresso when you need to know the app actually works on Android.

They can live together.

A healthy Android test pyramid could look like this:

Many unit tests
Some Robolectric tests
Some Kaspresso UI tests
A few Appium E2E tests only if cross-platform is needed

---

Installing Kaspresso

In your app module, add the dependency to build.gradle.kts.

dependencies {
    androidTestImplementation("com.kaspersky.android-components:kaspresso:1.6.1")
}

Make sure you have an instrumentation runner:

android {
    defaultConfig {
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }
}

You will also usually have AndroidX test dependencies already:

dependencies {
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
    androidTestImplementation("androidx.test:runner:1.6.2")
    androidTestImplementation("androidx.test:rules:1.6.1")
}

Version numbers change. Check Maven Central before copying this into a real project six months from now.

---

Basic project structure

Kaspresso tests live in:

app/src/androidTest/java/your/package/name/

A simple structure:

androidTest/
└── java/
    └── com/example/app/
        ├── screens/
        │   ├── LoginScreen.kt
        │   └── HomeScreen.kt
        └── tests/
            └── LoginTest.kt

The important idea: keep UI locators in screen classes, not directly inside every test.

Bad:

@Test
fun loginWorks() {
    onView(withId(R.id.email)).perform(typeText("demo@test.com"))
    onView(withId(R.id.password)).perform(typeText("password"))
    onView(withId(R.id.loginButton)).perform(click())
    onView(withId(R.id.homeTitle)).check(matches(isDisplayed()))
}

Better:

@Test
fun loginWorks() = run {
    step("Enter login credentials") {
        LoginScreen {
            email.replaceText("demo@test.com")
            password.replaceText("password")
        }
    }

    step("Tap login") {
        LoginScreen {
            loginButton.click()
        }
    }

    step("Check home screen") {
        HomeScreen {
            title.isDisplayed()
        }
    }
}

That is the whole point: tests should read like actions, not like matcher soup.

---

Creating a screen object

Example LoginScreen.kt:

package com.example.app.screens

import com.example.app.R
import com.example.app.ui.LoginActivity
import com.kaspersky.kaspresso.screens.KScreen
import io.github.kakaocup.kakao.edit.KEditText
import io.github.kakaocup.kakao.text.KButton

object LoginScreen : KScreen<LoginScreen>() {

    override val layoutId: Int = R.layout.activity_login
    override val viewClass: Class<*> = LoginActivity::class.java

    val email = KEditText { withId(R.id.email) }
    val password = KEditText { withId(R.id.password) }
    val loginButton = KButton { withId(R.id.loginButton) }
}

Example HomeScreen.kt:

package com.example.app.screens

import com.example.app.R
import com.example.app.ui.HomeActivity
import com.kaspersky.kaspresso.screens.KScreen
import io.github.kakaocup.kakao.text.KTextView

object HomeScreen : KScreen<HomeScreen>() {

    override val layoutId: Int = R.layout.activity_home
    override val viewClass: Class<*> = HomeActivity::class.java

    val title = KTextView { withId(R.id.homeTitle) }
}

The exact imports can differ depending on your version and app setup, but the pattern is what matters.

Each screen class describes what exists on the screen.

The test describes what the user does.

Do not mix those two unless you want a maintenance mess later.

---

Writing a Kaspresso test

Example LoginTest.kt:

package com.example.app.tests

import androidx.test.ext.junit.rules.ActivityScenarioRule
import androidx.test.ext.junit.runners.AndroidJUnit4
import com.example.app.screens.HomeScreen
import com.example.app.screens.LoginScreen
import com.example.app.ui.LoginActivity
import com.kaspersky.kaspresso.testcases.api.testcase.TestCase
import org.junit.Rule
import org.junit.Test
import org.junit.runner.RunWith

@RunWith(AndroidJUnit4::class)
class LoginTest : TestCase() {

    @get:Rule
    val activityRule = ActivityScenarioRule(LoginActivity::class.java)

    @Test
    fun userCanLogin() = run {
        step("Enter credentials") {
            LoginScreen {
                email.replaceText("demo@test.com")
                password.replaceText("password")
            }
        }

        step("Submit login form") {
            LoginScreen {
                loginButton.click()
            }
        }

        step("Verify home screen is opened") {
            HomeScreen {
                title.isDisplayed()
            }
        }
    }
}

This is the style I like for UI tests.

Not too abstract. Not too clever. Not a page object religion.

Just enough structure so the test is readable.

---

Common commands

Here are the commands you will actually use.

The Gradle command is what you will use most of the time.

The adb shell am instrument command is useful when debugging or when your CI setup is custom.

---

Common Kaspresso/Kakao actions

This is the stuff you use every day.

Example:

LoginScreen {
    email.replaceText("demo@test.com")
    password.replaceText("password")
    loginButton.click()
}

Simple. Readable. No ceremony.

---

Using steps properly

Kaspresso steps are not just decoration.

They make logs readable.

Bad:

@Test
fun checkoutWorks() = run {
    CatalogScreen { item.click() }
    CartScreen { checkout.click() }
    PaymentScreen { cardNumber.replaceText("4111111111111111") }
    PaymentScreen { pay.click() }
    SuccessScreen { title.isDisplayed() }
}

Better:

@Test
fun checkoutWorks() = run {
    step("Open product from catalog") {
        CatalogScreen {
            item.click()
        }
    }

    step("Go to checkout") {
        CartScreen {
            checkout.click()
        }
    }

    step("Enter payment details") {
        PaymentScreen {
            cardNumber.replaceText("4111111111111111")
            pay.click()
        }
    }

    step("Verify successful order") {
        SuccessScreen {
            title.isDisplayed()
        }
    }
}

When this fails in CI, you do not want to guess where it died.

Steps give you a readable story.

---

Using Kautomator for system UI

Sometimes your test leaves the app.

Examples:

• Android permission dialogs
• notification shade
• system settings
• another app
• file picker
• camera/gallery picker

This is where UI Automator comes in. Kaspresso includes Kautomator for a nicer DSL.

Example idea:

import com.kaspersky.components.kautomator.component.common.views.UiView

object PermissionDialog {
    val allowButton = UiView { withText("Allow") }
}

Then in a test:

step("Allow notification permission") {
    PermissionDialog.allowButton.click()
}

Text can change by Android version and language, so be careful. System UI tests are always more fragile than normal app UI tests.

If you can avoid system dialogs in most tests, avoid them.

For one smoke test, fine.

For every test, pain.

---

Handling flaky tests

Kaspresso has flaky-safety mechanisms that retry actions/assertions for a period of time instead of instantly failing on small UI timing issues.

That helps with real Android UI automation because apps are not perfectly synchronous.

But here is the important part:

Do not use flaky safety as an excuse to write bad tests.

If the app needs 10 seconds to show a button because the backend is slow, fix the test setup. Mock the backend, seed data, disable animations, or control the state.

Flaky safety should protect against small UI timing issues.

It should not hide broken architecture.

Practical anti-flake checklist:

Useful emulator setup:

adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0

This alone removes a lot of nonsense.

---

Recommended test style

Use this simple pattern:

Arrange
Act
Assert

For UI tests:

Prepare app state
Open screen
Perform user action
Check result

Example:

@Test
fun wrongPasswordShowsError() = run {
    before {
        // clear user/session state if needed
    }.after {
        // cleanup if needed
    }.run {
        step("Open login screen") {
            // activity rule already opened it
        }

        step("Enter invalid credentials") {
            LoginScreen {
                email.replaceText("demo@test.com")
                password.replaceText("wrong-password")
                loginButton.click()
            }
        }

        step("Verify error message") {
            LoginScreen {
                errorText.hasText("Invalid email or password")
            }
        }
    }
}

The point is not to make it fancy.

The point is to make it obvious.

A test should be boring to read.

Boring tests are usually good tests.

---

What to test with Kaspresso

Do not automate everything through the UI.

That is how teams create a slow and flaky monster.

Good Kaspresso test candidates:

Bad Kaspresso test candidates:

The UI suite should be small and valuable.

Not huge and miserable.

---

Kaspresso vs Espresso vs Appium vs Robolectric

Here is the practical comparison.

My rule:

Tools are not religions.

Use the tool that matches the test layer.

---

CI setup idea

A basic CI flow:

name: Android UI Tests

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  ui-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: Run Android tests
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 35
          target: google_apis
          arch: x86_64
          script: ./gradlew connectedDebugAndroidTest

This is enough to start.

Later you can add:

• screenshots as artifacts
• Allure report
• test retries
• sharding
• managed devices
• Firebase Test Lab
• different Android API levels

But do not start with a monster setup.

Make one reliable test run first.

Then expand.

---

Common mistakes

The worst automation suites are not bad because of the tool.

They are bad because nobody controlled the scope.

Kaspresso helps, but it will not save a chaotic test strategy.

---

My practical setup recommendation

If I were adding Kaspresso to a real Android project, I would start like this:

Start small.

One stable test is better than twenty flaky ones.

For the first batch, I would automate:

After that, stop and evaluate.

Are the tests stable? Are failures easy to debug? Is CI too slow? Are selectors good? Do developers actually run them?

If the answer is no, fix the foundation before writing more tests.

---

Final take

Kaspresso is what I would use when plain Espresso starts feeling too raw, but Appium feels too heavy.

It keeps you inside the Android ecosystem, gives you readable Kotlin test code, and adds the kind of things QA engineers actually need: steps, logs, screenshots, flaky handling, and system UI support.

It will not magically make bad tests good.

But if your Android app needs a real UI regression suite, Kaspresso is a very reasonable choice.

My honest recommendation:

Use Kaspresso for a small number of high-value Android UI tests.

Use unit tests and Robolectric for the lower layers.

Use Appium only when cross-platform coverage is actually required.

That setup gives you coverage without turning the test suite into a slow circus.