Приложение-песочница: как iOS-разработчики автоматизируют рутинные задачи

Ускоряем создание и тестирование новых UI компонентов, а заодно чиним процессы.

В конце лета мы столкнулись с проблемой — разработка UI слоя нашего iOS-приложения стала невыносимо долгой. Особенно если речь шла о сложном компоненте, который требовал постоянно запускать приложение, чтобы проверить изменения в коде. Ведь помимо сборки проекта, нужно ещё и добраться до экрана, где используется этот компонент. На это уходит не меньше минуты. И так может происходить десятки раз за день. В общем, печальная ситуация. Как мы из неё выходили, рассказывает iOS-разработчик Андрей Морозов.

Мы решили создать отдельное приложение-песочницу, в котором можно проверить текущие наработки и посмотреть уже готовые элементы.

Наши ожидания от него были такие:

Для удобства решили не мудрить с архитектурой и остановились на варианте, когда в приложении есть всего один экран со списком ячеек. А дальше к нему могут подключаться разные варианты UI компонентов. При таком подходе у нас получилось несколько основных секций: элементы управления (controls), views, ячейки и экраны. В каждом из них есть набор вложенных экранов, ведущих к готовым UI-элементам.

Теперь все новые и независимые UI компоненты создаются в отдельном легковесном модуле/библиотеке, которая может быть одновременно использоваться как в нашей песочнице, так и основном приложении Joom.

Жить стало легче. Казалось бы, мы достигли своей цели — ускорили разработку UI и можем спокойно развивать продукт дальше… но сердце подсказывало, что теперь мы способны решить и другие проблемы!

Меньше всего нам хочется, чтобы наши пользователи сталкивались с плохим или кривым интерфейсом в приложении. А еще мы совсем не любим тратить время QA-команды на поиск и прогон рутинных сценариев, где UI выходит из-под контроля и ведёт себя некорректно, например, на маленьких устройствах или на иностранных языках. Также мы поддерживаем right-to-left (RTL) локализацию, в которой интерфейс должен отображаться зеркально. При таком разнообразии контента риск не уследить за особым случаем (например, iPhone SE в сочетании с арабской локалью) довольно высок.

Мы пробовали добавлять чек-листы, чтобы разработчики лишний раз видели напоминание о необходимости проверить интерфейс на различных размерах устройств и локализациях. Но ощутимого эффекта это не возымело. Поэтому иногда общение с командой тестирования выглядело примерно так:

На этом моменте пришла идея, что раз у нас уже есть sandbox с готовыми UI компонентами, то можно переложить все необходимые и рутинные проверки на бездушную машину.

Для решения этой проблемы идеально подходят snapshot тесты. Это такой вид тестирования, когда изначально сохраняется снимок эталонного (reference) UI компонента, а потом его текущее состояние сравнивается с записанным ранее. В результате этой проверки можно автоматически найти расхождение между двумя снимками одного элемента.

Например, был записан reference снимок ячейки с описанием магазина.

Затем кто-то из разработчиков по ошибке изменил расстояние между блоками с дополнительной информацией (рейтинг, количество отзывов и подписчиков).

После запуска snapshot тестов мы увидим сообщение об ошибке с прикрепленным изображением.

На снимке видна разница между двумя предыдущими скриншотами – эталонным и актуальным (в нашем случае сломанным) состояниями интерфейса: расположение элементов изменилось и требует исправлений.

Для таких тестов мы используем библиотеку swift-snapshot-testing, позволяющую делать снимки UI компонентов и затем автоматически сравнивать их.

Остаётся открытым один вопрос – как удобно организовать запись скриншотов, не напрягая при этом разработчиков?

Самым логичным решением было переиспользовать песочницу. Приложение отлично выполняет одну функцию — предоставляет ячейки с UI элементами для отображения в виде списка. Это значит, что если пройтись по нему, то можно как записать эталонные снимки имеющихся компонентов, так и получить их актуальное состояние во время тестирования, чтобы провести сравнение.

Благодаря этому подходу наши snapshot тесты получились настолько простыми, что не страшно включить их код в статью:

Остался последний штрих – тесты для right-to-left локализаций.

Начиная с Xcode 11 появился механизм Test Plans, позволяющий запускать одни и те же тесты в разном окружении. Поэтому мы создали две идентичных конфигурации: Default и RTL, которые отличаются лишь настройкой языка приложения:

Теперь мы можем автоматически запускать snapshot тесты сразу в двух локализациях и получать снимки для right-to-left вёрстки тоже:

На текущий момент у нас 33 теста и 184 снимка UI компонентов в различных состояниях. Общий прогон всех тестов в двух конфигурациях занимает ~ 17 секунд. Это правда очень быстро!

В результате мы полностью изменили наш подход к созданию новых UI компонентов — отныне они живут в отдельном модуле, добавляются в приложение-песочницу и обязательно покрываются snapshot-тестами во всех возможных вариациях контента.

Вдобавок простое решение одной проблемы помогло нам улучшить ещё несколько смежных процессов.

Ну а главное — мы стали намного счастливее! О долгой сборке проекта при работе над UI слоем можно забыть, а разрабатываемый компонент сразу виден в песочнице и не скрывается глубоко в приложении 🚀

Если вам интересна тема поддержки разных языков в продукте, то рекомендуем прочитать статью от наших коллег про Figma плагин для автоматизации переводов в макетах.