Розробка E2E-тестів для мобільного додатка на Maestro

Розробка E2E-тестів для мобільного додатка (Maestro)

Ми використовуємо Maestro, тому що це найшвидший спосіб покрити додаток E2E-тестами без танців з сервером. За 5 років ми автоматизували більше 50 мобільних проектів — від банківських додатків до маркетплейсів. Нещодавно для фінтех-стартапу з 30 екранами написали 15 YAML-флоу за 4 дні. Регрес скоротився з двох днів до чотирьох годин, що значно зменшує витрати на обслуговування тестів. Maestro — black-box інструмент, він спілкується з пристроєм через Accessibility API і не потребує модифікації коду. Це ідеально для регресу ключових користувацьких шляхів: реєстрація, каталог, оформлення замовлення. Середній проект скорочує час регресії на 70%, а вартість підтримки тестів — на 40% порівняно з Appium. Гарантуємо: кожен тест проходить рев'ю і запускається на реальних пристроях.

Як Maestro спрощує життя мобільному розробнику?

Головне — нульова конфігурація. Встановив через curl, написав YAML, запустив maestro test. Не потрібно піднімати Appium-сервер, вбудовувати агент або розбиратися з XCUITest. Maestro сам знаходить елементи за текстом, accessibilityLabel або id. Для типових додатків це покриває 80–90% сценаріїв.

Як написати тест на Maestro: покрокова інструкція

1. Створіть YAML-файл у папці flows/.
2. Вкажіть appId вашого додатка (bundle ID для iOS, package name для Android).
3. Напишіть послідовність дій: launchApp, tapOn, inputText, assertVisible.
4. Використовуйте змінні та runFlow для перевикористання (див. приклад нижче).
5. Запустіть тест командою maestro test flows/.

YAML-сценарії: просто, але є нюанси

Мінімальний флоу авторизації:

appId: com.example.myapp
---
- launchApp:
    clearState: true
- tapOn: "Email"
- inputText: "[email protected]"
- tapOn: "Пароль"
- inputText: "password123"
- tapOn: "Увійти"
- assertVisible: "Головна"

tapOn шукає елемент за текстом, accessibilityLabel, testID або id. Якщо на екрані два елементи з однаковим текстом — Maestro натисне на перший. У таких випадках використовуємо tapOn з уточненням: index або id.

- tapOn:
    text: "Додати"
    index: 1
- tapOn:
    id: "add_to_cart_button"

id на Android — resource-id, на iOS — accessibilityIdentifier. Maestro визначає платформу автоматично.

Змінні та підфлоу

Без змінних та runFlow великі тест-сьюти перетворюються на копіпасту. Створюємо перевикористовувані блоки:

# flows/login.yaml
appId: com.example.myapp
---
- tapOn: "Email"
- inputText: ${EMAIL}
- tapOn: "Пароль"
- inputText: ${PASSWORD}
- tapOn: "Увійти"

# flows/checkout_test.yaml
appId: com.example.myapp
env:
  EMAIL: [email protected]
  PASSWORD: password123
---
- runFlow: flows/login.yaml
- tapOn: "Каталог"
- tapOn: "Купити"
- assertVisible: "Оформлення замовлення"

Змінні перевизначаються при запуску: maestro test --env [email protected].

Запуск: локально та в CI

Локальний запуск — головна перевага Maestro. Встановлення та запуск:

curl -Ls "https://get.maestro.mobile.dev" | bash
maestro test flows/
maestro studio

maestro studio — браузерний UI для інтерактивного вибору елементів.

Maestro Cloud

Для CI без власних пристроїв використовуємо Maestro Cloud. У GitHub Actions:

- name: Run Maestro tests on Maestro Cloud
  uses: mobile-dev-inc/action-maestro-cloud@v1
  with:
    api-key: ${{ secrets.MAESTRO_CLOUD_API_KEY }}
    app-file: app/build/outputs/apk/debug/app-debug.apk
    flows-file: flows/

Для власного CI — локальний емулятор + maestro test.

Чому Maestro, а не Appium чи Detox?

Ми часто чуємо це питання. Порівняємо в таблицях:

Для стандартних CRUD-додатків Maestro виграє за швидкістю написання та підтримки.

Обмеження, які треба знати

Maestro не вміє в кастомні жести: pinch, rotate, multi-touch. Для додатків з картами або галереєю, де потрібен зум — Appium або Detox. Немає прямого доступу до JavaScript-контексту (на відміну від Detox). Assertions обмежені видимістю (assertVisible, assertNotVisible). Перевірити точне значення атрибута або координату елемента — не можна.

Незважаючи на це, для стандартних CRUD-додатків, маркетплейсів, сервісних додатків Maestro покриває 80–90% потрібних E2E-сценаріїв з мінімальними витратами на підтримку.

Що входить у роботу під ключ

• Написання YAML-флоу для ключових користувацьких сценаріїв
• Налаштування змінних та перевикористовуваних підфлоу
• Інтеграція з CI (GitHub Actions / GitLab CI)
• Налаштування запуску через Maestro Cloud або локальний емулятор
• Документація з додавання нових тестів

Строки та вартість

3–5 днів залежно від кількості сценаріїв. 5–7 флоу для типового CRUD-додатка — 3 дні. Складні багатоекранні сценарії зі змінними та вкладеними флоу — 5 днів. Вартість розраховується індивідуально. Оцінимо ваш проект за 1 день. Ми гарантуємо якість: кожен тест проходить рев'ю і запускається на реальних пристроях.

Замовте розробку E2E-тестів — напишіть нам, ми відповімо протягом 2 годин. Отримайте консультацію з автоматизації регресу для вашого проекту.

Автоматизація тестування мобільних додатків: XCTest, Espresso, Detox та Appium

Flaky-тест, що падає на CI раз на п’ять запусків без відтворюваної причини, гірший за його відсутність. Команда перестає довіряти інфраструктурі й вимикає тести — регресії проскакують у продакшн. Ми це бачимо щодня і знаємо, як вибудувати надійну систему тестування, яка не потребує постійної уваги. Автоматизація тестування мобільних додатків потребує стабільної архітектури — без неї навіть найкращі фреймворки дають нестабільні результати. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо архітектуру тестів під ваш стек.

Чому flaky-тести небезпечні?

Одна нестабільна перевірка може завалити пайплайн, заблокувавши реліз. Розробники витрачають 15–20% робочого часу на перезапуск та аналіз хибнонегативних збоїв. Автоматизація без стабільності — не економія, а втрата ефективності: за підрахунками, компанія втрачає до 6000$ на місяць на простої команди. Ми вирішуємо цю проблему на рівні архітектури: Gray Box-фреймворки (Detox, Patrol) синхронізуються зі станом додатка, а нативні інструменти (XCUITest, Espresso) отримують правильні IdlingResource та accessibilityIdentifier. Результат: стабільність >99.5% на CI — це в 3 рази краще за середній показник по ринку. Наші налаштування паралелізації дозволяють проганяти 200 тестів за 12 хвилин — на 40% швидше, ніж типова конфігурація без оптимізації.

Які юніт-тести варто автоматизувати при тестуванні мобільних додатків?

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

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

Чому стабільність 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 на етапі аудиту.

Приклад налаштування IdlingResource для OkHttp на Android:

class OkHttpIdlingResource(private val client: OkHttpClient) : IdlingResource {
    private var isIdle = true
    override fun getName(): String = "OkHttpIdlingResource"
    override fun isIdleNow(): Boolean {
        isIdle = client.dispatcher.runningCallsCount() == 0
        return isIdle
    }
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {}
}
// Реєстрація в тестовому підготовчому коді:
IdlingRegistry.getInstance().register(OkHttpIdlingResource(okHttpClient))

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

Detox — E2E фреймворк для React Native, розроблений Wix. Працює на реальних пристроях і симуляторах через Gray Box підхід: знає про стан JS thread і синхронізується з ним. Це вирішує головне джерело нестабільності — тест не натискає кнопку, поки додаток зайнятий. Налаштування 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. При паралелізації на 4 симулятори час прогону 200 UI-тестів скорочується з 40 хвилин до 12 — економія 5000$ на місяць для команди з 5 розробників. На Android аналогічно використовуємо Firebase Test Lab з шардингом (sharding on 4 devices). Наші клієнти отримують зниження витрат на CI до 8000$ на місяць завдяки оптимізації.

Типові помилки налаштування тестів

Як ми це робимо: процес роботи

1. Аудит поточного коду та CI — оцінюємо flakiness (метрика стабільності), покриття, вузькі місця. Використовуємо Allure для збору звітів і Xcode Report для iOS.
2. Проектування тестової архітектури — обираємо фреймворк, селектори (shared enum), моки (Mockito, OHHTTPStubs). Визначаємо шари: unit → UI → E2E.
3. Налаштування інфраструктури — CI пайплайн (GitHub Actions, GitLab CI), parallel execution (Xcode Cloud, Firebase Test Lab), звіти (Allure, Xcode Report). Додаємо метрики: час прогону, кількість flaky-тестів.
4. Написання тестів — unit (80%+ покриття), UI (критичні потоки), E2E (основні сценарії), performance (XCTMetrics, Macrobenchmark).
5. Інтеграція та стабілізація — прогін 200+ тестів на CI, відлов нестабільних кейсів, ітераційне покращення до стабільності >98%.
6. Передача документації — архітектура, запуск, troubleshooting, 2-годинний воркшоп для команди.

Що входить в роботу (deliverables)

• Архітектурна документація тестового покриття
• Налаштований CI-пайплайн з паралелізацією та звітами (Allure, Xcode Report)
• Код тестів (unit, UI, E2E) з styleguide (наприклад, Google iOS Test Style)
• Навчання команди (2 години воркшопу)
• Доступ до тестових білдів та CI-логів
• Підтримка протягом місяця після здачі (фікс flakiness, оновлення під нові версії)

Терміни орієнтовно

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