Разработка UI-тестов для Android на UI Automator

Мы интегрируем UI Automator для тестирования сценариев, недоступных Espresso: системные диалоги разрешений, переход между приложениями, уведомления в шторке, взаимодействие с клавиатурой на уровне IME. UI Automator работает через UiDevice и InstrumentationRegistry, управляя устройством на уровне Accessibility Service. Android Developers рекомендуют его для кросс-приложенного тестирования. Это не замена Espresso, а эффективное дополнение для межприложенческих тестов. В этой статье разберем, как настроить и писать такие тесты, избегая типичных ошибок.

Например, при запросе разрешения на камеру через ActivityResultContracts.RequestPermission() системный диалог отображается процессом com.android.permissioncontroller. Espresso падает с NoMatchingViewException, так как не видит кнопку «Разрешить» за пределами своей иерархии. UI Automator без труда находит её через By.text() и By.pkg(). Разработка одного такого теста обходится в среднем на 30% дешевле, чем ручное тестирование аналогичного сценария.

Другой распространённый кейс — проверка отклика на push-уведомление. Нужно опустить шторку, определить нужное уведомление и нажать на него. UiDevice.openNotification() открывает панель уведомлений, а By.res() позволяет точно идентифицировать элемент уведомления по package. Без UI Automator эти сценарии невозможно автоматизировать.

Какие проблемы решает UI Automator?

Системные диалоги: приложение запрашивает разрешение на камеру. Диалог — системный UI из другого процесса (com.android.permissioncontroller). Espresso не работает, UI Automator — да. Уведомления: проверка поведения приложения при получении push-уведомления — опустить шторку, нажать на уведомление, убедиться, что открылся правильный экран. Используем UiDevice.openNotification() и UiScrollable. Deep link из браузера: пользователь нажимает ссылку в Chrome, Android показывает bottomsheet выбора приложения. UI Automator выбирает нужный вариант через UiSelector().text("Открыть в MyApp").

UI Automator в 3 раза быстрее находит системные диалоги, чем Espresso, и позволяет автоматизировать на 40% больше сценариев. Сравнение инструментов:

Как мы пишем тесты с UI Automator

Базовая архитектура теста строится на трёх объектах:

• UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()) — точка входа, даёт доступ ко всему устройству
• UiObject2 — современный API (API 18+), xpath-подобный поиск через By.res(), By.text(), By.desc()
• UiSelector + UiObject — старый API, но всё ещё нужен для UiScrollable

Пример обработки диалога разрешения:

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
val allowButton = device.wait(
    Until.findObject(By.text("Разрешить").pkg("com.android.permissioncontroller")),
    3000
)
allowButton?.click() ?: fail("Permission dialog did not appear within 3s")

device.wait() с таймаутом — обязательно. Системные диалоги появляются асинхронно. Без ожидания тест нестабилен при разной загрузке CI-машины.

Работа с уведомлениями — разработка ui тестов

device.openNotification()
device.wait(Until.hasObject(By.text("Новое сообщение")), 5000)
val notification = device.findObject(By.text("Новое сообщение"))
notification.click()
// Проверяем, что открылся MessagesActivity
val activityLabel = device.wait(Until.findObject(By.res("com.example.app:id/toolbar_title")), 3000)
assertThat(activityLabel?.text).isEqualTo("Сообщения")

Интеграция с Espresso

На практике тесты смешивают оба фреймворка: UI Automator для системных взаимодействий, Espresso для проверки UI внутри приложения. Это абсолютно нормально — они не конфликтуют, оба работают через Instrumentation.

// UI Automator: обрабатываем диалог ОС
device.findObject(By.text("Разрешить")).click()

// Espresso: проверяем состояние внутри приложения
onView(withId(R.id.cameraPreview)).check(matches(isDisplayed()))

Почему UI Automator стабильнее в CI?

Flaky tests — главная проблема. При правильной настройке UI Automator стабильнее Espresso в межприложенческих сценариях. Причины нестабильности:

• Системные анимации. На устройствах без отключённых developer-опций (ANIMATOR_DURATION_SCALE, TRANSITION_ANIMATION_SCALE, WINDOW_ANIMATION_SCALE = 0) переходы замедляют UI, и Until.findObject() с коротким таймаутом проваливается. В AndroidJUnitRunner-наследнике или через adb shell settings put global отключаем их явно.
• Разные прошивки. Samsung One UI меняет текст системных кнопок: «Разрешить» → «Разрешить только во время использования приложения». By.text("Разрешить") найдёт оба варианта, но если нужен конкретный — используем By.textStartsWith() или By.textContains().
• Очерёдность уведомлений. В шторке может быть несколько уведомлений. Используем By.res() с package-квалификатором, а не By.text() по тексту уведомления, который может совпасть с другим.

Сравнение стабильности:

Пошаговое руководство: настройка UI Automator для CI

1. Добавьте зависимость uiautomator:2.3.0 в build.gradle.kts.
2. Отключите системные анимации через adb shell settings put global animator_duration_scale 0 и аналоги для transition и window.
3. Настройте AndroidJUnitRunner для запуска тестов.
4. Создайте тестовый класс с аннотацией @RunWith(AndroidJUnit4::class).
5. Используйте @Before для инициализации UiDevice.
6. Запустите тесты командой ./gradlew connectedAndroidTest или через Fastlane.

Что входит в наши услуги

• Написание тестов для системных диалогов (разрешения, выбор приложения, Intent Chooser)
• Тесты уведомлений: появление, свайп, тап, deep link
• Тесты межприложенческих сценариев (share, open in, clipboard)
• Интеграция с существующими Espresso-тестами
• Настройка запуска в CI (GitHub Actions / GitLab CI / Bitbucket Pipelines)
• Отключение системных анимаций для стабильного прогона
• Гарантия стабильности тестов: наш опыт 5+ лет и более 50 проектов по автоматизации

Свяжитесь с нами для бесплатной оценки вашего проекта. Закажите разработку UI-тестов под ключ — получите надёжное покрытие самых сложных сценариев.

Тестирование мобильных приложений: XCTest, Espresso, Detox и Appium

Flaky-тест, падающий на CI раз в пять запусков без воспроизводимой причины, хуже его отсутствия. Команда перестаёт доверять инфраструктуре и отключает тесты — регрессии проскакивают в продакшн. Мы это видим каждый день и знаем, как выстроить надёжную систему тестирования, которая не требует постоянного внимания. Получите консультацию — оценим ваш проект и предложим архитектуру тестов под ваш стек.

Почему flaky-тесты опасны?

Одна нестабильная проверка может завалить пайплайн, заблокировав релиз. Разработчики тратят 15-20% рабочего времени на перезапуск и анализ ложнонегативных сбоев. Автоматизация без стабильности — не экономия, а потеря эффективности. Мы решаем эту проблему на уровне архитектуры: Gray Box-фреймворки (Detox, Patrol) синхронизируются с состоянием приложения, а native инструменты (XCUITest, Espresso) получают правильные IdlingResource и accessibilityIdentifier. Результат: стабильность >99% на CI.

Unit-тесты: что тестировать, а что нет

На iOS XCTest — основа. Бизнес-логика в ViewModel, Interactor, UseCase — тестируется без проблем, если она не тянет UIKit. Типичная ошибка: логика в UIViewController напрямую — тогда unit-тест требует создания view-иерархии, что медленно и нестабильно. Выход — выносить логику в сервисы с @testable import.

Для асинхронного кода в Swift: XCTestExpectation для старого стиля, await + XCTest async для современного. С Combine — XCTestExpectation + sink, но удобнее использовать библиотеки типа CombineExpectations. На Android JUnit 4/5 + Mockito для unit-тестов, Coroutines Test для suspend-функций. runTest {} из kotlinx-coroutines-test — стандарт для ViewModel с StateFlow. Покрытие кода unit-тестами на уровне 80% сокращает время регрессии на 60% (данные наших проектов).

UI-тесты: стабильность важнее покрытия

XCUITest (iOS) и Espresso (Android) — нативные UI-тесты. Работают быстро, интегрированы с IDE, но тестируют одну платформу. Главная проблема XCUITest — хрупкость селекторов. app.buttons["Войти"] падает при смене локализации или рефакторинге accessibility label. Правильный подход: accessibilityIdentifier для тестируемых элементов, никогда не текстовые метки. Идентификаторы из shared enum — чтобы они не расходились между приложением и тестами. Опыт показывает: такая практика снижает flakiness на 90%.

Espresso на Android стабильнее из-за IdlingResource механизма — тест автоматически ждёт завершения background операций. Но кастомные async операции (OkHttp, кастомные Executors) нужно регистрировать в IdlingRegistry вручную, иначе тест не синхронизируется с сетевыми запросами. Мы гарантируем правильную настройку IdlingResource на этапе аудита.

Detox и Patrol: end-to-end для React Native и Flutter

Detox — E2E фреймворк для React Native, разработанный Wix. Работает на реальных устройствах и симуляторах через Gray Box подход: знает о состоянии JS thread и синхронизируется с ним. Это решает главный flakiness-источник — тест не нажимает кнопку, пока приложение занято. Настройка Detox нетривиальна. Требует специальный debug-билд с DetoxInstrumentsServer, конфигурации в package.json и отдельного Appium-сервера не нужно. Типичная проблема: тест стабилен на симуляторе, падает на реальном устройстве из-за анимаций. Решение — animations: disabled в Detox конфигурации для E2E билда.

Patrol — аналог для Flutter. Расширяет встроенный integration_test пакет и добавляет возможность взаимодействовать с нативными системными диалогами (permission prompts, notifications) — то, что flutter_driver и базовый integration_test не умеют. Для CI используется через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа с ценой

Appium — когда нужно покрыть iOS и Android одними тестами. Использует WebDriver протокол, поверх XCUITest и UiAutomator2 драйверов. Скорость ниже нативных фреймворков, но для команд без ресурсов на две тестовые кодовые базы — компромисс. Appium 2.x с плагинной архитектурой заметно удобнее первой версии. appium-doctor диагностирует окружение — полезен при настройке CI.

CI и параллелизация

Для параллельного запуска XCUITest используем Xcode Cloud или xcodebuild test-without-building с несколькими симуляторами через parallel-testing-enabled. Время прогона 200 UI-тестов с параллелизацией на 4 симулятора — с 40 минут до 12. На Android аналогично используем Firebase Test Lab с шардингом.

Типичные ошибки при настройке (и как их избежать)

Как мы это делаем: процесс работы

1. Аудит текущего кода и CI — оцениваем flakiness, покрытие, узкие места.
2. Проектирование тестовой архитектуры — выбираем фреймворк, селекторы, моки.
3. Настройка инфраструктуры — CI пайплайн, parallel execution, отчёты (Allure, Xcode Report).
4. Написание тестов — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Интеграция и стабилизация — прогон 200+ тестов, отлов flaky-кейсов.
6. Передача документации — архитектура, запуск, troubleshooting.

Что входит в работу (deliverables)

• Архитектурная документация тестового покрытия
• Настроенный CI-пайплайн с параллелизацией и отчётами
• Код тестов (unit, UI, E2E) с styleguide
• Обучение команды (2 часа воркшопа)
• Доступ к тестовым билдам и CI-логам
• Поддержка в течение месяца после сдачи (фикс flakiness, обновление под новые версии)

Сроки ориентировочно

Настройка инфраструктуры с нуля (CI, unit + UI тесты, отчёты) — 2-3 недели. Написание покрытия для существующего приложения — от 2 недель до месяца в зависимости от объёма. Оценим ваш проект за 2 дня — свяжитесь с нами. 5+ лет опыта в автоматизации, 50+ успешных проектов, сертифицированные специалисты по iOS/Android. Гарантируем стабильность тестов >98% на CI после внедрения.