Espresso — що це, принципи роботи та як використовувати

Що таке Espresso?

Espresso — це бібліотека для написання автоматизованих UI-тестів для Android, яка входить до складу Google AndroidX Test. Вона надає API для пошуку View-елементів на екрані, виконання дій над ними (натискання, введення, свайп) та перевірки їхнього стану (відображається, містить текст, активний).

Ключова особливість Espresso — автоматична синхронізація з головним потоком додатку. Фреймворк очікує завершення всіх асинхронних завдань (корутини, AsyncTask, Handler) перед виконанням наступної перевірки. Це виключає flaky-тести, пов'язані з race condition, і робить UI-тести стабільними та надійними — жоден тест не містить Thread.sleep() або циклів очікування.

Espresso слідує принципу Three-Legged Dog — тест складається з трьох кроків: знайти елемент (ViewMatcher), виконати дію (ViewAction), перевірити результат (ViewAssertion). Усі три кроки записуються в ланцюжок викликів onView().perform().check(). Ця концепція робить тести передбачуваними та легко читаними — кожен тест явно описує, що шукає, що робить і що перевіряє.

Як працює Espresso

Архітектура Espresso заснована на трьох компонентах: Espresso (точка входу — статичні методи onView та onData), ViewMatchers (пошук елементів), ViewActions (дії) та ViewAssertions (перевірки). Всередині фреймворк використовує Idling Resource для синхронізації з UI-потоком.

Базовий тест Espresso

Найпростіший тест знаходить кнопку за ID, виконує натискання та перевіряє, чи з'явився текст «Готово». Всі операції виконуються синхронно з точки зору тесту — Espresso гарантує, що UI-потік завершив обробку події до того, як тест продовжить виконання. Це досягається завдяки вбудованому механізму очікування: onView блокує виконання тесту, поки UI не стане стабільним.

@Test
fun buttonClick_showsSuccessText() {
    // Знайти кнопку за ID і натиснути
    onView(withId(R.id.button_submit))
        .perform(click())

    // Перевірити, що текст «Готово» відображається
    onView(withText("Готово"))
        .check(matches(isDisplayed()))
}

Правило ActivityScenario

Для запуску Espresso-тесту використовується ActivityScenario (AndroidX Test), який створює Activity у потрібному стані — запущена, призупинена, знищена. ActivityScenario дозволяє тестувати життєвий цикл Activity на додаток до чистого UI. Наприклад, можна перевірити, що дані зберігаються при повороті екрану (recreation Activity) та відновлюються після знищення.

ViewMatchers: пошук UI-елементів

ViewMatchers — це набір методів із класу Espresso.onView, які дозволяють знайти View на екрані за різними критеріями: ідентифікатором ресурсу (R.id), текстом, hint-підказкою, батьківським елементом та ієрархією. Якщо один матчер не дає унікального результату, матчери комбінуються через allOf().

Комбінація матчерів

Якщо на екрані декілька однакових елементів (наприклад, два TextView з різним текстом), зручно комбінувати матчери через allOf: onView(allOf(withId(R.id.title), withText(«Привіт»))). Це гарантує вибір єдиного елемента. Зворотний оператор — not() — виключає елементи з пошуку, а hasSibling() шукає елемент поруч із відомим.

ViewActions: взаємодія з UI

ViewActions — це дії, які Espresso виконує над знайденим View: click(), typeText(), clearText(), scrollTo(), swipeLeft() та інші. Дії передаються в метод perform(), який може приймати декілька дій підряд.

Ланцюжок дій

Метод perform() приймає vararg ViewAction, що дозволяє виконати послідовність дій над одним елементом: очистити поле, ввести новий текст, закрити клавіатуру та натиснути кнопку. Всі дії виконуються в порядку їх перерахування, а Espresso гарантує, що попередня дія завершена до початку наступної.

// Введення тексту в EditText і натискання кнопки
onView(withId(R.id.edit_email))
    .perform(
        clearText(),
        typeText("user@example.com"),
        closeSoftKeyboard()
    )

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

Перевірка через onData

Для елементів всередині AdapterView (ListView, RecyclerView) використовується метод onData() замість onView. Він працює з даними адаптера, а не з View — знаходить елемент за вмістом моделі та повертає відповідний View для подальших дій. onData використовує hamcrest-матчери для пошуку елемента за полями моделі даних.

ViewAssertions: перевірка стану

ViewAssertions перевіряють, що View знаходиться в певному стані. Базовий метод — matches(matcher) — перевіряє, що елемент відповідає заданому матчеру. Додатково Espresso пропонує doesNotExist() (елемент відсутній) та selectedDescendantsMatch() (перевірка вкладених елементів).

Типові перевірки

Найбільш часті перевірки в UI-тестах: елемент відображається (isDisplayed), елемент містить певний текст (withText), елемент активний (isEnabled), елемент не вибраний (isNotChecked). Кожна перевірка викидає докладний виняток у разі невдачі — із зазначенням ієрархії View на екрані. Це спрощує налагодження: у повідомленні про помилку видно, які елементи реально були на екрані в момент перевірки.

Кастомні ViewAssertions

Якщо стандартних перевірок недостатньо, можна створити власну через інтерфейс ViewAssertion. Кастомний assertion отримує View та може перевірити його стан програмно — наприклад, колір тексту, відступи або стан кастомного компонента, не розкритого через стандартні матчери.

// Перевірка: TextView відображається і містить текст
onView(withId(R.id.text_welcome))
    .check(matches(isDisplayed()))
    .check(matches(withText("Ласкаво просимо")))

// Перевірка: елемент НЕ відображається
onView(withId(R.id.progress_bar))
    .check(doesNotExist())

Idling Resources для асинхронних операцій

Idling Resource — це механізм Espresso для синхронізації тесту з асинхронними операціями. За замовчуванням Espresso очікує завершення Handler, AsyncTask та корутин (через coroutinesIdlingResource). Якщо додаток виконує фонову роботу через власні потоки або Callback-сервіси, необхідно зареєструвати кастомний Idling Resource.

Приклад з корутинами

Починаючи з AndroidX Test 1.4.0, Espresso підтримує корутини через CoroutinesIdlingResource. Тест автоматично очікує завершення всіх запущених корутин, перш ніж виконувати перевірки UI. Для більш складних сценаріїв використовуються CountingIdlingResource — лічильник, який інкрементується при старті задачі та декрементується при завершенні.

// Реєстрація IdlingResource для OkHttp
class OkHttpIdlingResource(
    private val client: OkHttpClient
) : IdlingResource {

    private var isIdle = true
    private var watcher: IdlingResource.ResourceCallback? = null

    override fun getName() = "OkHttp"

    override fun isIdleNow() = isIdle

    override fun registerIdleTransitionCallback(
        callback: IdlingResource.ResourceCallback
    ) {
        watcher = callback
    }
}

Налаштування Espresso в Android-проєкті

Підключення Espresso в Android-проєкт виконується через додавання залежностей у build.gradle рівня модуля. Espresso входить в AndroidX Test, тому достатньо вказати залежності для ядра Espresso, розширень та JUnit-інтеграції. Тести розміщуються в директорії src/androidTest та запускаються на фізичному пристрої або емуляторі через AndroidJUnitRunner.

Gradle-конфігурація

Мінімальний набір залежностей включає espresso-core (ядро), espresso-contrib (додаткові матчери для RecyclerView, Drawer, Picker) та runner (тестовий раннер AndroidX). Всі тести запускаються на емуляторі або фізичному пристрої через Android Test Orchestrator.

// build.gradle.kts (androidTest залежності)
android {
    defaultConfig {
        testInstrumentationRunner =
            "androidx.test.runner.AndroidJUnitRunner"
    }
}

dependencies {
    androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
    androidTestImplementation("androidx.test.espresso:espresso-contrib:3.6.1")
    androidTestImplementation("androidx.test:runner:1.6.1")
    androidTestImplementation("androidx.test:rules:1.6.1")
}

Запуск тестів на CI

Espresso-тести можна запускати через Google Android Test Orchestrator, який ізолює кожен тест в окремий процес та очищає стан між запусками. Це усуває flaky-тести, пов'язані з залишковими даними попередніх тестів, та підвищує стабільність на CI-серверах. Для паралельного запуску використовується sharding — розподіл тестів між декількома емуляторами.