UI-tests in Android. Часть 1. Что это и зачем

Предположим вы андроид разработчик. И для начала предположим вы пишете новый проект.

Вот вы закончили основной функционал, теперь нужно выкатывать в продакшен/релизить/выпускать обновление в гугл плей маркет. Что вы сделаете? Наверно протестируете ваш функционал, чтобы быть более менее уверенным в том, что все работает корректно. Ок. Предположим вы работаете не в одиночку и у вас в команде есть тестировщик. Тогда на его долю упадет ответственность за тестирование приложения и всего функционала. Предположим этого функционала не так много и он справился за пару часов. А если у вас в команде нет тестировщика, например вы пишете проект в одиночку. Тогда эти пару часов уйдет из вашего времени. Вроде как немного, правда? Что такого, пару часов потратить на то, чтобы быть уверенным, что все сделано на совесть. Но это до следующего релиза или же до первой баги.

Итак, предположим вы выкатываете новый функционал или же внесли некоторые правки в существующий. Что теперь? Вам тестировать не только новые фичи, но еще и старые, верно? Здесь мы предположили, что вы не переписали полностью с нуля все и вся и некоторая часть того, что было в первом релизе осталась и в этом. Значит вам опять тратить несколько часов на тестирование функционала, верно? Ну или тестировщику. Ок. А если это была бага и вы пофиксили ее — значит вам еще тестировать, что она действительно перестала воспроизводиться. А теперь такой вопрос — а что если это был критический баг и вам нужно быстренько залить хотфикс? У вас есть 3 часа на ручное тестирование? Если да, то ок. А если нет? И начальство требует сделать хотфикс как можно скорей? Подождите, шеф, надо потестировать функционал. Некогда! Выпускайте уже! Окей…. И вот оказалось, что ваш багфикс затронул основной функционал и вы опять имеете баг и так бесконечно. Или до тех пор, пока вы решаете перед релизом тестировать весь фунцкионал добросовестно. Значит перед каждым релизом у вас уже будет уходить на X времени больше при каждой новой фиче или багофиксе. Верно? Сначала у вас был 1 экран и 1 фича, потом 2 фичи. И вот прошло 3 месяца и вам уже нужно 3 человека, которые бы тестировали весь функционал приложения целый день. Хорошо, если на проверку функционала уходит 1 день. А если это перерастает уровень HelloWorld, то тогда тесткейсов становится действительно много. Это называется временем регресса. Т.е. момент, когда вы отдаете сборку на тестирование и просто ждете, пока эту сборку протестируют полностью и тогда уже можно выкатывать в гуглплей новую версию. И конечно же бизнесу важно чтобы время регресса было как можно меньше. Ведь время это деньги. А время 5 человек это деньги умноженные на 5.

Итак, юай тесты. Вот наш бизнесмен думает — о боже! Каждый релиз нашего приложения это 3 дня тестирования! Было бы замечательно уменьшить это время до 3 часов хотя бы. Или еще лучше, до 30 минут. И вот вам решение — юай тесты.

Если вы читали про юнит тесты, то вам более менее понятно что такое тесты в принципе. Отличие юай тестов в том, что эти тесты используют… юай! Сюрприз! И для проверки юай тестов вам нужен девайс. Или физический или же эмулятор. Что из себя представляет сам юай тест — джава/котлин код, который пишется 1 раз и его можно запускать перед каждым релизом. А если еще настроить такую замечательную вещь как CI/CD (DEVOPS) то эти тесты будут автоматически проверяться перед каждым релизом. Т.е. представьте на секунду. Вы написали новые фичи и вам нужно релизить — вы просто нажимаете 1 кнопку — все юай тесты прогоняются за полчаса и вуаля — вы прекрасны. Можно выкатывать в продакшн сборку. А еще можно уволить 3 тестировщиков. Ведь они не нужны. Можно оставить в принципе 1 из них или пускай разработчик сам пишет юай тесты. Они пишутся немного долго, но это зависит от тест кейсов (что такое тест кейс наверно отдельной статейкой распишу).

Еще раз. У вас есть энное количество фичей, вы решаете добавить еще одну и при этом знать, что ничего не затронули из рабочего кода. Для этого вы запускаете после написания все существующие юай тесты и после прохождения их пишете юай тесты на новый функционал и вуаля. Вы можете со спокойной душой выкатывать в релиз новую сборку.

Кто-то скажет, что у нас нет времени писать юай тесты. Мы быстренько руками будет проверять каждый раз весь функционал. Да неужели? У вас нет времени написать пару сотен строк кода, но у вас есть несколько часов каждый раз проверять функционал? Т.е. у вас нет времени написать юай тест и спокойно релизить, но у вас есть время при возникновении баги быстро делать хотфикс и релизить 2 раза на неделе? Как же вы плохо относитесь к вашим разработчикам. Ведь самый большой стресс для разработчика это хотфикс. Когда каким-то образом возникла бага и ее нужно срочно фиксить.

Надеюсь я вас убедил, что юай тесты нужны. А если нет, то вот вам второй случай. Вы пришли на старый проект где есть уже существующий код. Что вам нужно сделать? Конечно же разобраться в нем. Но увы и ах, вы опять же единственный разработчик, а тестировщика или нет или же он тоже новый и не ведает все прелести приложения.

А начальство вам говорит — разберись в проекте, пофиксь багу и сделай новую функциональность. И здесь начинается русская рулетка. Естественно никаких юай тестов в проекте нет. Ведь если бы они были, ты бы их просто прочитал или запустил и понял бы что к чему. Но вот незадача, раньше был программист, который считал что юай тесты не нужны и не написал ни единого. А тем временем в проекте 100.000 строк кода. Да начнется игра! Ты, как сапер, должен в сжатые сроки понять что к чему, пофиксить багу, которой 3 месяца и допилить функционал. А теперь вопрос, как ты можешь быть уверен, что старый функционал который худо бедо работал ты не задел? Вот именно, вся надежда на новичка тестировщика — т.е. оставь надежду и просто заплачь.

Что бы сделал человек, который знаком с юай тестами? Он бы написал их. Да, на существующий проект написал бы юай тесты, ведь примерно он видит в коде что и как. После этого он бы начал фиксить баги и на них тоже написал бы юай тесты. А после уже новый функционал — и юай тесты на него. Тогда уже он был бы более менее уверен, что не сделал проекту только хуже. Ведь у проекта как никак есть аудитория и они сильно расстроятся, если новый разработчик привнесет в стабильные части проекта новые баги.

Как убедить начальство, что тебе нужно немного времени на юай тесты? Легко!

Вот вы не писали юай тесты, верно? Сколько у вас багов? 38. А если бы писали юай тесты то их бы было гораздо меньше. Как считаете, стоит ли оно того, чтобы потратить немного больше времени на написание кода и юай тестов чтобы после релиза не делать хотфиксы и забыть уже об огромной доле багов, котроые никак не пофиксятся?

И здесь опять можно возразить — у нас стартап, у нас нет времени. Окей. Как же так — времени делать качественно нет, но тратить каждую неделю на багфикс у вас время есть? Поймите наконец — если не обращать внимание на качество работы, то рано или поздно проект превратится в тыкву, в которую просто невозможно будет вносить изменения.

Вот вы убедили начальство, написали юай тесты. Они прогоняются перед каждым релизом за полчаса и вы спокойно пишете новый функционал. А баги становятся все реже и реже. Ведь вы при каждой новой фиче пишете тонну другую ай тестов. Заметьте, сам код (нетестовый) может быть самым худшим в мире, без архитектуры и т.д. Но если ваши юай тесты подтверждают, что все работает прекрасно, вы можете со спокойной душой приступить к такому страшному делу как рефакторинг. ДА! Это еще одно из плюсов юайтестов. Вы пишете юай тесты на существующий проект. После этого рефакторите весь проект и если после этого все юай тесты также зеленые (т.е. проходят), значит вы качественно порефакторили проект.

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

Запись опубликована в рубрике Программирование Android. Добавьте в закладки постоянную ссылку.