Автотесты: за и против

Интервью с Рустамом Кенджаевым, руководителем группы мобильной разработки Яндекс Маркета

— Самое главное преимущество автотестов я как разработчик вижу в том, что они повышают уровень доверия к изменениям в коде. Когда команда разрабатывает новую фичу, никто не защищён от возможности поломать какой-нибудь неочевидный сценарий. Одна из самых популярных болей на синках — «Я написал код, но не знаю, как и что он поменяет в других частях продукта».

Когда разрабатываешь тест сам, начинаешь смотреть на написанный код немного по-другому. Разбираясь, как обработать показ ошибок бэкенда и сети, что проверить при перезаходе в фичу и как себя чувствуют диплинки, лучше понимаешь, что именно написал. Это помогает быстрее найти и исправить ошибки, а значит, выкатить более качественную фичу. И защитить её от коллег: чтобы убедиться, что следующий релиз не сломает написанную тобой функциональность, им достаточно будет запустить готовые автотесты. У команды Маркета есть негласное правило: чинит не тот, кто что-то сломал, а тот, кто не покрыл место поломки проверками.

Один из самых популярных аргументов противников автотестов — необходимость искать время на их написание: зачем тратить несколько минут, чтобы сделать что-то вручную, если можно потратить несколько часов на попытки это автоматизировать?

Я с этой шуткой не согласен. Если внедрение автотестов занимает у вас слишком много времени, значит, надо пересмотреть процесс их разработки: проверьте, правильно ли вы готовите моки, пейдж-обджекты и локаторы для UI-тестов. Хорошо написанные тесты существенно ускоряют и облегчают поиск ошибок.

В iOS-команде Маркета сейчас 35 человек. Мы работаем по принципу Trunk Based Development. И не раз бывало, что ночные прогоны автотестов утром спасали нас от долгого выяснения, чей коммит сломал транк: достаточно было проверить отчёты. А искать проблему в 10–50 строчках одного коммита гораздо приятнее, чем полностью перепроверять код релиза на 30 000 строк.

Ещё один важный плюс автотестов — они помогают воспроизвести даже самые редкие сценарии: то, что заняло бы человеко-часы и человеко-дни, зачастую укладывается в несколько минут автоматизированных проверок. Мне попадался очень интересный и редкий сценарий, с которым мало кто из пользователей Маркета сталкивался вживую: его помогли обнаружить автотесты. Представьте, что вы одновременно заказали телефон и чехол к нему. Если чехла вдруг не будет на складе, телефон вы всё равно получите. А вот если в наличии не окажется телефона, зачем вам один только чехол? Приложение Маркета предупредит вас об этой неприятности и отменит заказ.

Я люблю автотесты: они ускоряют запуск новых фичей, помогают сделать каждый релиз как можно более жизнеспособным, экономят время разработчиков, силы тестировщиков, нервы пользователей и средства компании. Но было бы несправедливо не упомянуть об их минусах.

Во-первых, внедрение автотестов требует большого количества железных ресурсов. Во-вторых, иногда возникают проблемы с их идемпотентностью: это значит, что несколько прогонов теста в одном и том же окружении могут привести к разным результатам (обычно такие тесты игнорируют как непоказательные). В-третьих, некоторые проверки выполняются довольно долго: прогон одного автотеста фронтенда для Маркета в среднем укладывается в 10–13 минут. А для мобильных приложений (и Android, и iOS) — может длиться около часа. Но нас это вполне устраивает, поскольку сопоставимо с временными затратами на код-ревью, которое также занимает не меньше часа.