Почему мы перешли на Selenide, попутно написав более 200 новых автотестов

Привет, я автоматизатор тестирования на одном из проектов крупной компании. В этой статье я расскажу, почему мы приняли решение перейти с Serenity на Selenide. Задача у нас масштабная, и хотя изменение технологического стека заняло определенное время, впоследствии оно с лихвой окупилось за счет ускорения написания тестов и выполнения регресса.

Прежде чем переходить к сути, немного о задаче в целом.

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

Весь объем функционала разбит на несколько проектов: телефония, пользовательская панель и админка. Все три проекта находятся в активной разработке. А моя задача заключается в автоматизации тестирования на этих проектах в широком смысле слова.

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

Обновление стека

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

Selenide — достаточно популярный инструмент, для которого есть много готовых решений. Часть возможностей Selenide доступна и у аналогов — Atlas, Selenium, HTMLElements и т.п. Но каждый из них по-своему нам не подходил.

Selenium лежит в основе Selenide. Но для наших целей он слишком низкоуровневый. Нет смысла изобретать велосипед, когда есть готовое решение.

Atlas появился совсем недавно. Он достаточно сырой и не имеет поддержки Groovy.
HtmlElements всем хорош, но устарел и не поддерживается. Есть еще JDI, но в нем возникли проблемы с многопоточностью.

Serenity, ранее использовавшийся на проекте, был слишком громоздким. В нем все настолько взаимосвязано, что для добавления какого-то нового обработчика или перехватчика событий приходилось переписывать десяток классов (и это не каждый раз приводило к успеху). Плюс к Serenity не получалось подключить Allure — фактический отраслевой и внутрикорпоративный стандарт для генерации тестовых отчетов.

В Selenide с точки зрения автоматизатора все гораздо проще. Например, нет необходимости отдельно описывать шаги — привязываться к методам и т.п. Поскольку у него есть поддержка Allure из коробки, в тестовый отчет автоматически попадают все действия по работе с веб-элементами.

Разумеется, у Selenide есть поддержка PageFactory, Page Object и PageElement. Это делает код более читаемым. Плюс предусмотрены внутренние ожидания того момента, когда элемент появится, — нет необходимости явно прописывать, что нужно остановить тест на несколько секунд, прежде чем идти дальше (предельное время ожидания устанавливается в конфигах). Отдельно существуют и явные ожидания — можно на каждом тестовом шаге явно переопределить таймаут для нужных элементов.

Удобно, что у Selenide есть целый набор всевозможных готовых методов.

Так как на старте перехода с Serenity на Selenide я был один в команде, то дополнительным плюсом было то, что у меня уже был достаточный опыт на Selenide и Groovy, поэтому я мог быстро внедрить готовые решения и впоследствии тратить меньше усилий на их поддержку.

Переход был практически безболезненный. Мы внедрили Selenide в связке с Allure. Allure позволяет создавать читаемые и даже в чем-то красивые отчеты, по которым наглядно видно, какие шаги упали и с какой ошибкой. “Из коробки” к отчетам можно прикладывать скриншоты веб-страниц. Мы даже добавляем видеозапись прогона, исходный код страницы, логи браузера и веб-драйвера.

Перенос существующих тестов потребовал минимума усилий. Что у Serenity, что у Selenide — PageObject-ы с аннотациями @FindBy. У Serenity и Allure используются те же аннотации шагов @Step. Пришлось обновить модель, вложенность элементов друг в друга, порядок вызова тестовых шагов. Какие-то тесты полностью удалили, какие-то переписали с нуля, а где-то хватило просто актуализации локаторов. По сути переезд стал тривиальной задачей, с которой сталкиваются большинство UI-автоматизаторов при редизайне веб-приложения.

Обновление тестов

После обновления технологического стека взялись за сами тесты. К слову, часть этой работы уже была выполнена в рамках перехода на новый стек.

Учитывая накопившееся отставание от функциональности проектов, их все равно пришлось бы переписывать заново — это выгоднее по времени, чем искать нестыковки в таком объеме кода.

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

Имея небесконечные временные ресурсы, мы всегда стараемся направить усилия на то, что позволит нам сократить трудозатраты на поддержку, максимально покрыв функционал. Сейчас покрытие автотестами слегка перевалило за 50%.

Переписанные тесты на Selenide стали компактнее и аккуратнее за счет многократного переиспользования кода — все благодаря возможностям самой библиотеки.

Обновляя тесты, мы учитывали, что их нужно запускать одновременно (в несколько потоков). Тесты и раньше запускали на отдельных виртуальных машинах. Но переход на Selenide позволил еще больше распараллелить задачу, запуская их в несколько потоков.

Грубо говоря, сам переход на новый фреймворк увеличил нам количество одновременно запущенных потоков с 3 до 8, а последующая оптимизация тестов — до 50. В итоге 100 UI-тестов пробегают буквально за 10 минут.

Многопоточность, кстати, — это еще одно преимущество, за которое мы выбрали Selenide. Здесь нет этой большой прослойки boilerplate, пишешь минимум кода. Нет и лишней писанины, необходимой в Selenium для подготовки проекта к запуску. Все, необходимое для запуска тестов, есть уже “из коробки”.

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

Уже целой командой мы смогли оптимизировать регрессионное тестирование. Если раньше регресс занимал у команды 7 дней, то теперь те же самые задачи выполняются 4 дня, т.е. мы сократили время работы тестов почти в 2 раза.

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

Естественно, мы будем развивать и инфраструктуру тестирования. В планах внедрение Mock-сервера. Сейчас мы тестируем все на реальном стенде, генерируя тестовые данные. Это отнимает время и ресурсы. Mock-сервер позволит запускать автотесты без этой предварительной подготовки (мы писали о mock-сервере для другого проекта).

Также планируем внедрить запись автотестов, чтобы можно было писать сценарий TestRail на основе заготовки, полученной непосредственным прокликиванием интерфейса в браузере. На выходе мы получим своего рода прототип автотеста.

Автор статьи: Юрий Кудрявцев, Специалист по автоматизированному тестированию программного обеспечения.

Наши статьи по теме:

Все статьи

Связаться с нами

Мы свяжемся с вами в течение 24 часов.