UI Automator: какво е това, ключови понятия и как работи

Какво е UI Automator?

UI Automator е рамка за функционално UI тестване на Android, която работи на ниво операционна система. Тя предоставя API за достъп до всеки елемент на екрана на устройството, независимо от кое приложение е — включително системната лента за състояние, диалози за разрешения, началния екран и приложения на трети страни. Това я прави незаменима за тестване на сценарии, които излизат извън рамките на едно приложение.

Архитектурно, UI Automator използва Accessibility Service — същата услуга, която се използва от TalkBack, Switch Access и други инструменти за достъпност. Чрез тази услуга рамката получава пълното дърво на UI компонентите на текущия екран и позволява изпълнението на действия върху тях: кликване, плъзгане, въвеждане на текст, продължително натискане.

UI Automator се появи за първи път в Android 4.3 (API 18) и оттогава е част от Android Testing Support Library като официален инструмент на Google за междуприложно тестване. В AndroidX Test е достъпен като отделен артефакт androidx.test.uiautomator:uiautomator версия 2.3.0 (2024), който поддържа всички версии на Android от API 18.

Как работи UI Automator

Принципът на работа на UI Automator се основава на сканиране на Accessibility дървото на текущия екран. При извикване на метода findObject(selector), рамката обхожда йерархията на View, намира първия елемент, който отговаря на условията на UiSelector, и връща обект UiObject — прокси за взаимодействие с реалния View.

Жизнен цикъл на UI Automator тест

Типичен UI Automator тест започва с получаване на инстанция на UiDevice, която представлява физическото устройство. UiDevice предоставя методи за търсене на елементи, управление на натискания на бутони (Home, Back, Recent), завъртане на екрана и правене на екранни снимки. След намиране на елемента чрез UiSelector се изпълняват действия върху UiObject.

Основен пример

В примера по-долу тестът отваря приложението Settings, намира елемента „Батерия“ по текст и кликва върху него. UI Automator не изисква стартиране на Activity — работи с всеки екран на устройството, включително приложения на трети страни.

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

// Отвори екрана с настройки
device.pressHome()
device.wait(Until.hasObject(UiSelector().text("Настройки")), 2000)

// Намери елемента „Батерия“ и натисни
val batteryItem = device.findObject(
    UiSelector().text("Батерия")
)
batteryItem.clickAndWait(Until.newWindow(), 3000)

UiDevice и UiSelector: ключови класове

UiDevice — основният клас за взаимодействие с устройството. Той предоставя методи за търсене на елементи, симулиране на натискания на хардуерни бутони (Home, Back, Menu, Volume), управление на захранването, правене на екранни снимки и изчакване на определени състояния на екрана. UiDevice се създава веднъж на тест и се преизползва за всички операции.

UiSelector — това е fluent API за търсене на UI елементи. За разлика от ViewMatchers в Espresso, UiSelector не изисква компилация — условията за търсене се формират чрез верига от методи: text(), className(), description(), resourceId(), index(). Няколко условия се комбинират автоматично чрез логическо И.

Пример за търсене с няколко условия

Когато на екрана има няколко елемента с един и същ текст, UiSelector позволява комбиниране на критерии: намиране на контейнера по ID, след това вътре в него — елемента по текст и клас. Това гарантира уникална идентификация на необходимия компонент. Методът childSelector стеснява областта на търсене до посочения контейнер, което ускорява навигацията в UI дървото.

val scrollView = device.findObject(
    UiSelector().resourceId("android:id/list")
)

// В списъка намери елемента с текст „Wi-Fi“
val wifiItem = scrollView.findObject(
    UiSelector().text("Wi-Fi")
wifiItem.click()

Cross-application тестване с UI Automator

Cross-application (междуприложно) тестване — основната функция, заради която се избира UI Automator. Рамката може да превключва между приложения, да тества OAuth вход чрез браузър, да проверява системни диалози (разрешения, избор на приложение) и да взаимодейства със системната лента за състояние, панела за известия и заключения екран.

Тестване на OAuth вход

Типичен сценарий за cross-app тест: приложението отваря браузър за OAuth авторизация, потребителят въвежда потребителско име и парола, браузърът пренасочва обратно към приложението. UI Automator превключва между процеси, намира полетата за въвеждане в браузъра, попълва ги и кликва върху „Вход“.

// Изчакване на появата на браузъра
device.wait(Until.hasObject(
    UiSelector().packageName("com.android.chrome")
), 5000)

// Търсене на полето за въвеждане на имейл в браузъра
val emailField = device.findObject(
    UiSelector().className("android.widget.EditText").instance(0)
)
emailField.text = "user@example.com"

Проверка на системни диалози

UI Automator може да проверява и затваря системни диалози — разрешения за геолокация, известия, достъп до файлове. Това е критично за тестване на първото стартиране на приложението, когато системата последователно иска няколко разрешения. Без UI Automator такива сценарии не могат да бъдат автоматизирани, тъй като системните диалози не принадлежат на процеса на приложението.

UI Automator vs Espresso: сравнение на подходите

Изборът между UI Automator и Espresso зависи от сценария на тестване. Espresso е оптимизиран за тестване на едно приложение с автоматична синхронизация и минимален boilerplate. UI Automator е подходящ за сценарии, които изискват взаимодействие със системата, браузъра или няколко приложения.

На практика тези рамки често се използват заедно: Espresso покрива UI тестовете на основното приложение с висока стабилност, а UI Automator се включва за сценарии, излизащи извън границите на приложението — OAuth вход, системни разрешения, работа с Share Intent. Тази комбинация дава максимално UI покритие при минимални разходи за поддръжка на тестовете.

Настройка на UI Automator в Android проект

Свързване на UI Automator се извършва чрез добавяне на зависимост в build.gradle. Рамката е част от AndroidX Test и не изисква допълнителни разрешения в манифеста — достъпът до Accessibility Service се конфигурира автоматично при стартиране на инструменталния тест.

Gradle зависимости

Минималната конфигурация включва артефакта uiautomator и стандартния тестов runner AndroidJUnitRunner. UI Automator тестовете се поставят в директорията src/androidTest и се стартират на емулатор или физическо устройство с Android API 18+.

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

UiDevice и конфигурация на тестовете

За получаване на инстанция на UiDevice се използва InstrumentationRegistry.getInstrumentation(). UiDevice трябва да се създаде веднъж в метода setUp() и да се преизползва във всички тестове на класа за пестене на ресурси на устройството. Важно е да се отбележи, че UiDevice не е thread-safe — всички операции трябва да се изпълняват в една нишка на тестовия метод. Създаването на нов UiDevice във всеки тест води до допълнително натоварване и забавяне на изпълнението. Препоръчва се създаване на UiDevice веднъж в метода beforeClass и преизползването му за всички тестове на тестовия клас.

Изчакване в UI Automator

За разлика от Espresso, UI Automator няма автоматична синхронизация. За изчакване на появата на елементи се използва методът UiDevice.wait(condition, timeout) с обекта Until: Until.findObject(selector), Until.hasObject(selector), Until.gone(selector). Без правилно изчакване тестовете стават нестабилни поради race condition — елементът може да не успее да се появи на екрана до момента на търсенето. Препоръчва се задаване на таймаут от поне 3-5 секунди за стабилност.