Build instrumented tests
Дає офіційну точку входу до native Android UI tests і synchronization model.
Типи мобільних застосунків та мобільна автоматизація → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
namespace package
Package, який може бути розподілений між кількома distributions. Native namespace packages доступні з Python 3.3 і не мають __init__.py у namespace directory.
__init__, self, page та принципи ООП →Вибір mobile automation strategy
Оберіть один власний mobile flow і визначте, що має перевірятися на backend, native component та system E2E levels.
Складіть мінімальну device matrix із поясненням кожного device та OS version.
Назвіть accessibility attributes, яких бракує для стабільних selectors.
Односторінкова strategy з test levels, device matrix і переліком testability changes.
React Native, Flutter і змішана стратегія
У React Native частина компонентів доступна як native UI, частина може поводитися як web content, а для platform-specific можливостей додається Swift або Kotlin code. Крім Appium, для такого стеку згадується Detox. Якщо продукт значною мірою рендериться як web view, більшу частину логіки іноді дешевше перевіряти Playwright-тестами на web-рівні, залишивши кілька справжніх mobile flows для інсталяції, permissions і наскрізної інтеграції. Flutter сам рендерить значну частину UI, тому accessibility tree і поведінка елементів можуть відрізнятися від стандартних native components. Це не робить Flutter автоматично добрим чи поганим: потрібен окремий proof of concept на реальному застосунку, перш ніж обирати automation stack.
Типи мобільних застосунків
На старті розрізняються native-застосунки для Android та iOS, hybrid/web-mobile рішення і cross-platform стеки на кшталт React Native, Flutter, Kotlin Multiplatform та Xamarin. Native Android переважно пишеться на Kotlin, iOS — на Swift або Objective-C; cross-platform рішення намагаються повторно використати частину коду між платформами. Стратегія тестування залежить не лише від технології UI, а й від розподілу логіки. Один застосунок може майже повністю містити контент і переходи локально, а інший бути тонким клієнтом для складного backend. Тому однакова кількість екранів ще не означає однаковий набір перевірок.
Platform guidelines, native, web і hybrid
iOS Human Interface Guidelines і Android Material guidelines задають expected platform behavior. Тестування має враховувати, що calendar, navigation, gestures і accessibility відрізняються між platforms. Мобільний product може бути responsive web, native, hybrid WebView або cross-platform. Hybrid app має native shell і web context, тому автоматизація має розуміти context switching й не трактувати все як однакову UI tree.
Native tests і внесок у testability
Для важливих або частих перевірок радиться розглянути 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 чи cross-platform: ціна абстракції
Cross-platform stack пришвидшує MVP та shared feature delivery, але platform-specific capabilities і UI differences нікуди не зникають. Зі зростанням product команди часто все одно ділять iOS/Android ownership. Для тестів це означає: shared business scenarios не гарантують identical platform behavior. Потрібно розділити shared domain behavior і platform-specific contracts, а не будувати великий conditional E2E suite.
Починати з product pain, а не з tool
Перше питання — що саме болить: release speed, regressions, platform drift, backend instability, device coverage чи migration. Далі з’ясовують product architecture, team ownership, roadmap і engineering maturity. Інструмент обирається після цього. Наприклад, планована migration з native на cross-platform або навпаки змінює test seams і робить speculative framework марним.
Чому один Appium-сценарій не гарантує однаковий тест
Appium і WebdriverIO дають спільний зовнішній API для iOS та Android, але додають кілька шарів комунікації між тестом, Appium server, platform driver і device. Через це сценарії повільніші, а діагностика instability складніша, ніж у native tests. Одна бізнес-дія також може мати різний UI на різних платформах: date picker, введення числа, back navigation і переходи між екранами підпорядковуються різним design guidelines. Відрізняється й lifecycle: після згортання або повернення екран може відновити state з local storage чи повторно звернутися до backend. Спільний тест часто все одно отримує platform-specific branches або окремі page/screen objects.
Devices, screen sizes і long-term delivery cost
Покриття має враховувати різні screen sizes, OS versions і representative devices, але не перетворюватися на cartesian product кожного scenario з кожним device. Cross-platform допомагає швидко отримати market feedback, але native plugins і diverging teams збільшують maintenance cost. Тест strategy має врахувати цей ceiling заздалегідь.