Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Поточна Android guidance окремо перелічує Espresso, UI Automator і Compose Test як instrumented UI testing APIs; конкретний seam потрібно обрати за UI surface та scope тесту.
Типи мобільних застосунків та мобільна автоматизація →Current Android guidance перелічує Espresso, UI Automator і Compose Test як окремі instrumented testing APIs. Це уточнює перелік інструментів із відео, але не встановлює універсальне mapping без аналізу конкретного UI.
Типи мобільних застосунків та мобільна автоматизація →Для важливих або частих перевірок радиться розглянути native інструменти: XCTest/XCUITest на iOS та Espresso або зручнішу обгортку Kakao на Android. Такі тести ближчі до застосунку, швидше виконуються і зрозуміліші mobile developers, які можуть запускати їх локально та в CI. Автоматизатор має покращувати testability самого продукту: додавати або просити додати стабільні `accessibilityIdentifier`, `accessibilityLabel`, Android `resource-id` і content descriptions. Native selectors, predicates і class chains зазвичай кращі за XPath. Якщо команда контролює source code, стабільний атрибут дешевший за постійне ускладнення locator-а в зовнішньому test suite.
Для native iOS згадується XCUITest, для Android — Espresso з wrapper на кшталт Kaspresso/Kakao, для React Native — Detox, для Flutter — Flutter Driver. Native tools мають коротший шлях до UI й швидше реагують на оновлення екрана. Складні canvas/builders, custom maps і довільна graphics interaction можуть бути дешевшими для ручної перевірки або вимагати окремої testability роботи з розробниками. Форми, списки та типові business flows автоматизуються значно простіше. **Актуальність станом на 2026-08-08.** Для нових Flutter integration tests офіційна документація веде до пакета `integration_test`, а для наявних `flutter_driver` suites дає окремий migration path ([Flutter documentation](https://docs.flutter.dev/release/breaking-changes/flutter-driver-migration)).