Тестирование мобилок — Detox, Maestro, ручное, когда что

Тестирование мобилок — отдельная статья расходов, которая часто превращается в кладбище. Команда настраивает e2e-фреймворк за месяц, через полгода никто его не запускает, патчи летят в прод без проверки.

Разбираем три рабочих подхода и где какой имеет смысл.

Ручное тестирование

Чеклист критических сценариев на 30-60 минут, тестировщик проходит перед релизом на 3-5 устройствах. Самый дешёвый и недооценённый подход.

Плюсы:

• Ловит проблемы UX, которые автотест не увидит.
• Не требует поддержки кода.
• Работает на реальных устройствах с реальными SIM, push, биометрией.

Минусы:

• Не масштабируется на 200 сценариев.
• Зависит от человека.

Подходит: приложения до 30-50 экранов, релизы раз в 2-4 недели, есть штатный QA.

Maestro

Open source. Сценарии — YAML, простые и читаемые. Запуск локально и в CI.

appId: com.example.app
---
- launchApp
- tapOn: "Войти"
- inputText: "user@example.com"
- tapOn: "Продолжить"
- assertVisible: "Главная"

Плюсы:

• Низкий порог входа — продакт может писать тесты.
• Один сценарий работает на iOS и Android (если приложения похожи).
• Maestro Cloud для запуска на ферме реальных устройств.

Минусы:

• Хуже работает с нетривиальной анимацией и кастомными жестами.
• Дебаг падений сложнее, чем у JS-фреймворков.

Подходит: 10-30 критических сценариев smoke + happy path, регулярно гоняются в CI.

Detox (React Native)

JS-фреймворк, написан под RN. Жирный, но интегрируется глубоко.

await element(by.id('email')).typeText('user@example.com');
await element(by.text('Войти')).tap();
await expect(element(by.id('home'))).toBeVisible();

Плюсы:

• Стабильнее Appium на RN.
• Глубокий доступ к состоянию приложения через моки.
• Хороший дебаг через Chrome DevTools.

Минусы:

• Тяжело настроить под кастомные нативные модули.
• Требует поддержки на стороне приложения (testID везде).
• Не работает с нативными iOS/Android приложениями.

Подходит: React Native проекты с серьёзной QA-командой и постоянными релизами.

Что не делать

• Покрывать e2e всё. 200 e2e-тестов = 4 часа CI, флакающие тесты, никто не смотрит.
• Полагаться только на unit-тесты. 90% багов мобилки — в интеграции экранов и в нативных API.
• Тестировать на эмуляторах вместо реальных устройств. Push, биометрия, камера, NFC — на эмуляторе не воспроизводятся.

Что работает в большинстве команд

1. 5-15 e2e-сценариев на Maestro для критического пути (логин, оплата, основной флоу).
2. Unit-тесты на бизнес-логику (расчёты, валидации) — Jest или XCTest/JUnit.
3. Ручной чеклист на 30 минут перед релизом, проходит штатный QA или сам разработчик.
4. Beta-канал для 50-200 пользователей (TestFlight / Google Play Internal) — ловит то, что автотесты пропустили.

Вывод

Полное e2e-покрытие мобилки в 90% проектов — это потерянные деньги. Реальная пирамида: 5-15 smoke-сценариев Maestro + unit на бизнес-логику + ручной чеклист + beta-канал. Detox оправдан только в больших React Native проектах. На нативных приложениях — Maestro почти всегда лучше Appium.