Пирамида тестов в мобильной разработке: как она выглядит на практике
Картинку с пирамидой — много юнит-тестов внизу, немного UI-тестов наверху — знают все. В вебе она работает неплохо. В мобильной разработке на практике чаще получается «рожок мороженого»: горстка юнитов и огромный слой медленных end-to-end сценариев, которые гоняются на ферме устройств по ночам.
Почему так происходит
Бизнес-логика мобильного приложения нередко размазана по экранам, а значит, проверить её без UI сложно. Плюс у QA-команды исторически больше компетенций в UI-автоматизации, чем в тестах на уровне модулей. Итог предсказуем: всё проверяется через интерфейс, прогоны занимают часы, а обратная связь приходит на следующий день.
Что можно сдвинуть вниз
- Валидацию и форматирование — суммы, даты, телефоны. Это чистые функции, им не нужен эмулятор.
- Маппинг ответов API — контрактные тесты на сериализацию ловят половину «экран не открылся».
- Навигацию и состояния экрана — компонентные тесты с замоканными зависимостями работают за секунды.
Что оставить наверху
End-to-end имеет смысл для критичных пользовательских путей: вход, оплата, ключевая конверсия. Их должно быть немного, и каждый должен отвечать на вопрос «что сломается для пользователя, если этот тест упадёт». Если ответа нет — сценарию место уровнем ниже.
Полезное упражнение: выгрузить список UI-тестов и для каждого честно отметить, проверяет ли он интерфейс или логику, которая просто случайно видна через интерфейс. Обычно вторых оказывается больше половины.