Налаштування тестування на реальних пристроях через Firebase Test Lab

Налаштування тестування на реальних пристроях через Firebase Test Lab

Емулятор бреше. Не зловмисно, але систематично: GPU-рендеринг інший, Bluetooth недоступний, камера симульована, поведінка пам'яті відрізняється від реального пристрою. Ми в TrueTech за 10+ років досвіду з мобільними проєктами стикалися з цим десятки разів. Firebase Test Lab надає доступ до фізичних пристроїв — Pixel 8, Samsung Galaxy S24, планшетів, старих Xiaomi з кастомними прошивками. Тест, який пройшов на емуляторі, може впасти на Samsung One UI через кастомний WebView або змінену систему дозволів. Замовте налаштування під ключ — ми підготуємо матрицю, Robo Script і CI-інтеграцію за 2–3 дні.

Чому емулятори підводять, а реальні пристрої — ні?

Емулятор не відтворює апаратні особливості: різну поведінку пам'яті, відсутність реальних датчиків (акселерометр, гіроскоп), емульовану камеру. На реальному пристрої виявляються проблеми з push-сповіщеннями (APNs/FCM), роботою у фоні (Background fetch) та глибокими посиланнями (Universal Links / App Links). За нашими даними, близько 30% крешів, виявлених на фізичних пристроях, не відтворюються на емуляторі. Використання Firebase Test Lab гарантує, що ваш застосунок готовий до реальних користувачів.

Що вміє Firebase Test Lab

Два режими тестування:

Instrumentation Tests — запускає ваші Espresso / XCUITest тести на обраних пристроях. Повний контроль над тим, що перевіряється.

Robo Test — автоматичний краулер. Запускаєте APK без жодного написаного тесту, Robo самостійно обходить інтерфейс по Accessibility-дереву, натискає кнопки, заповнює поля випадковими даними, шукає креші. Корисний для швидкої перевірки нових збірок перед релізом.

Підтримка платформ: Android (Espresso, UI Automator, Appium) та iOS (XCUITest). Firebase Test Lab для iOS — окрема історія з меншим парком пристроїв, але реальні iPhone та iPad все одно цінніші за симулятор.

Налаштування: від завантаження білда до результатів

Android

Складання APK та тест-APK:

./gradlew assembleDebug assembleAndroidTest

Завантаження та запуск через gcloud:

gcloud firebase test android run \
  --type instrumentation \
  --app app/build/outputs/apk/debug/app-debug.apk \
  --test app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk \
  --device model=Pixel8,version=34,locale=ru,orientation=portrait \
  --device model=a54xnsxx,version=13,locale=ru,orientation=portrait \
  --results-bucket gs://my-project-test-results \
  --results-dir "run_$(date +%Y%m%d_%H%M%S)"

model=a54xnsxx — це Samsung Galaxy A54. Список доступних моделей: gcloud firebase test android models list.

Матриця пристроїв

Вибір матриці — окрема аналітична задача. Немає сенсу ганяти тести на 50 пристроях. Принцип:

Реалістична матриця для більшості проєктів: 3–5 пристроїв. Більше — дорожче та довше, але не обов'язково інформативніше.

iOS

Для iOS потрібен .ipa з development-підписом (не distribution). Завантаження:

gcloud firebase test ios run \
  --test MyAppTests.zip \
  --device model=iphone15pro,version=17.4,locale=ru_RU,orientation=portrait

MyAppTests.zip — архів з .xctestrun файлом та тест-продуктами. Збирається через xcodebuild build-for-testing.

Robo Test з кастомним скриптом

Чистий Robo-краулер іноді застряє на екрані логіну — не знає облікові дані. Robo Script дозволяє задати початкові дії:

[
  {
    "eventType": "VIEW_TEXT_CHANGED",
    "replacementText": "[email protected]",
    "elementDescriptors": [{"resourceName": "com.example.app:id/email_input"}]
  },
  {
    "eventType": "VIEW_CLICKED",
    "elementDescriptors": [{"resourceName": "com.example.app:id/login_button"}]
  }
]

Після авторизації Robo продовжує обхід вже авторизованої частини застосунку. Це швидкий спосіб перевірити регресії без написання тестів.

Інтеграція в CI

GitHub Actions:

- name: Set up gcloud
  uses: google-github-actions/setup-gcloud@v2
  with:
    service_account_key: ${{ secrets.GCLOUD_SERVICE_ACCOUNT_KEY }}
    project_id: my-firebase-project

- name: Run tests on Firebase Test Lab
  run: |
    gcloud firebase test android run \
      --app app-debug.apk \
      --test app-debug-androidTest.apk \
      --device model=Pixel8,version=34 \
      --timeout 10m

Service account потрібен з роллю Firebase Test Lab Admin. Результати автоматично зберігаються у Cloud Storage — скріншоти, відео, логкати, XML-звіт.

Аналіз результатів

У консолі Firebase Test Lab для кожного запуску доступні:

• Відеозапис проходження тесту
• Logcat з фільтром за тегами
• Скріншоти в ключових точках
• Звіт про покриття (якщо включений jacoco)
• XML-результати у форматі JUnit (для Allure / Jenkins)

Що входить в налаштування під ключ

Ми пропонуємо повний цикл:

• Аналіз вашого парку пристроїв за даними аналітики
• Конфігурація матриці з 3–5 пристроїв
• Написання Robo Script для авторизації (якщо потрібно)
• Інтеграція в CI (GitHub Actions, GitLab CI, Bitrise)
• Навчання команди роботі з результатами
• Гарантія коректної роботи протягом 5 днів після здачі

Досвід наших інженерів — 40+ проєктів з Firebase Test Lab. Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальну конфігурацію.

Строки

2–3 дні — налаштування Firebase Test Lab, конфігурація матриці пристроїв, інтеграція в CI, налаштування Robo Script для авторизації. Плюс час на перший аналіз результатів та усунення пристроє-специфічних проблем. Вартість розраховується індивідуально.

Як Firebase Test Lab економить час на регресіях?

Robo-тести без жодного рядка коду знаходять креші та ANR на реальних пристроях швидше, ніж ручне тестування. За нашими даними, це економить до 40% часу QA-циклу. У поєднанні з Instrumentation-тестами ви отримуєте повне покриття за лічені години.

Автоматизація тестування мобільних додатків: 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 пайплайну просто зараз — отримаєте детальний звіт із рекомендаціями.