Maestro

Maestro — открытый фреймворк мобильного UI-тестирования от mobile.dev, в котором тесты описываются декларативными YAML-файлами (flows) и запускаются против iOS, Android, React Native и Flutter-приложений без инструментирования кода. Главная идея: нестабильность мобильных UI-тестов — проблема фреймворка, а не автора теста. Каждая команда Maestro автоматически ждёт появления элемента и повторяет действие при сбое, поэтому во flow нет ручных sleep и явных ожиданий. Весь инструмент — один бинарь maestro CLI: не нужен сервер-посредник, набор драйверов и словарь capabilities, как в Appium. За счёт этого порог входа радикально ниже: первый работающий тест пишется за минуты, а читать и править flow может человек без опыта программирования.

Как это работает

Flow — это YAML-файл со списком шагов: launchApp, tapOn, inputText, assertVisible, scrollUntilVisible и так далее:

appId: ru.example.app
---
- launchApp
- tapOn: "Войти"
- inputText: "user@example.org"
- assertVisible: "Профиль"

Записывать сценарии помогает Maestro Studio — графическая оболочка с инспектором: она показывает id и атрибуты любого элемента на экране и собирает YAML по вашим действиям. Команда maestro test flow.yaml одинаково работает с эмулятором и реальным устройством, а флаг --format junit из коробки отдаёт JUnit-XML отчёт, который понимает любой CI — GitHub Actions, Jenkins, GitLab CI.

Когда применять

Maestro силён там, где нужен быстрый и стабильный smoke/regression-слой поверх мобильного приложения: критические пользовательские пути, e2e-проверки релиз-кандидатов, сценарии, которые пишут и сопровождают QA без глубокой разработки. Сравнение с Appium честное в обе стороны: у Appium — W3C WebDriver-протокол, любой язык программирования, огромная экосистема и гибкость для сложных сценариев (кастомная логика, работа с несколькими приложениями, облачные фермы устройств); у Maestro — простота, скорость и устойчивость, но меньше свободы, когда сценарий выходит за рамки декларативных шагов. Для параллельных запусков у вендора есть Maestro Cloud, однако из РФ оплата зарубежного SaaS проблематична — практичная альтернатива: self-hosted запуск на Android-эмуляторах прямо в CI (headless-эмулятор в Docker/KVM-раннере) с шардированием флоу между параллельными джобами.

Типичные ошибки

• Тексто-зависимые шаги: tapOn по видимому тексту ломается при смене локали или копирайтинга — опирайтесь на id и accessibility-идентификаторы.
• Попытка выразить сложную условную логику в YAML: если flow оброс вложенными runFlow и JavaScript-вставками, вероятно, сценарию место в Appium, Espresso или XCUITest.
• iOS-тесты без macOS: симулятор iOS запускается только на macOS-раннере, в Linux-CI доступен лишь Android — планируйте матрицу заранее.
• Незакреплённая версия CLI: Maestro развивается быстро, поведение команд между версиями меняется — фиксируйте версию в CI, как любую другую зависимость.

Связанные понятия

• Тестирование мобильных приложений
• Appium
• Мобильные эмуляторы
• CI параллельно