Когда проект растёт, дольше всего начинают тянуться самые «тяжёлые» проверки – UI-тесты. Один-два модуля поменял, а CI всё равно гоняет сотни тестов на эмуляторах и ждёт их десятки, а то и сотни минут. Знакомо?

Это третья, финальная статья цикла о том, как мы в Циане перешли от полного прогона всех проверок к выборочному с помощью Impact-анализа. В первой части я показывал, как мы ускорили статические анализаторы, во второй — как в два раза сократили unit-тесты, научившись обходить граф Gradle-модулей. В заключительной части я расскажу, как у нас на проде реализован выборочный запуск UI-тестов.

Когда проект растёт, а вместе с ним — количество проверок, CI превращается в марафон. Мы в Циан через это прошли: кодовая база растёт, тестов становится всё больше, и каждое изменение начинает тормозить весь пайплайн.

В этой статье расскажу, как мы сократили время выполнения unit-тестов с помощью Impact-анализа — метода, который позволяет запускать только те тесты, которые действительно нужны. Это продолжение моего подхода к оптимизации проверок в Android — в первой статье я показывал, как ускорить статические анализаторы. Теперь — про unit-тесты.

Примеры кода будут на JUnit, но подход подходит ко всем проверкам, которые гоняются через Gradle. В конце статьи — рабочий пример на GitHub, который можно адаптировать под себя.

Когда команда растёт, а кодовая база стремительно увеличивается, время выполнения проверок может стать настоящей проблемой. Unit-тесты, UI-тесты, статический анализ — все эти процессы начинают занимать слишком много времени, замедляя разработку. Звучит знакомо?

В этой статье я поделюсь опытом нашей команды в Циан: расскажу, как мы перешли от полного выполнения всех проверок к выборочному запуску, снизив их длительность. И почему сделать это проще, чем кажется. Если вы считаете, что выборочный запуск статических анализаторов — это сложно и дорого в поддержке, я покажу, как обойтись всего 200 строками кода.

Хочется запускать проверки только там, где это действительно нужно, и ускорить работу своей команды? Тогда читайте дальше.

Знакома ли вам ситуация, когда вы спокойно работаете, а клиентская служба передаёт вам странный репорт: несколько пользователей жалуются, что в приложении не грузятся картинки, но у вас всё работает. Или пользователь пишет в Google Play, что приложение занимает несколько гигабайт, и вы не понимаете, сколько таких пользователей и что с этим делать. Нужно ли срочно бросаться чинить, или это может подождать следующего планового релиза?

Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»