Делимся практическим кейсом рефракторинга автотестов учетной системы: от линейных скриптов к архитектурному подходу, который ускорил написание тестов в три раза.

Технический долг в автотестах — это катастрофа, которая нарастает незаметно. Сначала «простые и быстрые» линейные скрипты кажутся хорошим решением, но с ростом продукта они превращаются в «спагетти-код», где любое изменение в интерфейсе вызывает часовую рутину правок. Мы прошли этот путь в проекте по разработке учетной системы и нашли выход через внедрение архитектурного паттерна Page Object Model (POM).

Состояние «до» с линейными автотестами

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

Однако по мере развития системы стали копиться проблемы архитектуры:

1. Нулевая переиспользуемость кода. Стандартные шаги вроде входа в систему, проверки загрузки документов дублировались в каждом тесте. Одна бизнес-логика описывалась десятками одинаковых строк.

2. Хрупкость кода. Изменение, например, одного селектор�� в UI требовало ручного поиска и правок во всех тестах, где этот элемент использовался. Это была «эффект домино» в чистом виде.

3. Высокий порог входа. Новым QA-инженерам приходилось тратить недели, чтобы разобраться в запутанной структуре. Это замедляло онбординг и повышало риски ошибок.

Техдолг в автотестах начал тормозить скорость разработки продукта. Перед командой стояла стратегическая задача: преодолеть технический долг и сделать систему автотестов устойчивой, масштабируемой и недорогой в поддержке - даже ценой временных затрат на рефакторинг. Именно поэтому мы приняли решение внедрить Page Object Model (РОМ).

Page Object Model (POM) - способ организовать автотесты так, чтобы каждая страница сайта описывалась отдельным классом. Каждый такой класс описывает элементы страницы (кнопки, поля, ссылки) и действия, которые можно с ними выполнить (например, «ввести логин» или «нажать “Купить”»).

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

Как мы перестраивали архитектуру

Переход к POM мы строили поэтапно, чтобы не останавливать процесс тестирования и при этом постепенно перестраивать архитектуру.

1) Выделили общие элементы

Мы выделили повторяющиеся элементы интерфейса - кнопки, поля ввода, формы - и описали их в виде универсальных классов. Общие элементы занимают порядка 70 % от всего кода, и повторять его из теста в тест нецелесообразно.

2) Описали страницы

Для каждой страницы приложения создали классы-обертки, инкапсулирующие все элементы и возможные действия. Так появилась понятная логика: страница = объекты с методами.

3) Сосредоточились на бизнес-логике в тестах

На верхнем уровне остались чистые тестовые сценарии, которые оперируют не техническими селекторами, а бизнес-методами. Например такими:

loginPage.enterCredentials().clickSubmit().

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

Результаты

Рассмотрим плюсы нашего решения:

1) Читаемость и качество кода

Тесты превратились в понятные бизнес-сценарии. Даже начинающие QA-инженеры видят логику выполнения и быстро разбираются в проекте.

2) Снижение стоимости поддержки

Изменения в UI не превращаются в часы рутинных правок. Обновление селектора в одном классе страницы автоматически применяется ко всем связанным тестам. В результате стоимость поддержки существенно снизилась: с новым подходом на поддержку уходило не 80% времени, а около 20%, что позволило увеличить покрытие автотестами до 95% за полгода.

3) Быстрый онбординг

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

4) Устойчивость к изменениям

Теперь даже крупные обновления продукта не вызывают «эффекта домино». Тестовая система стала гибкой, предсказуемой и легко расширяемой. Все новые тесты сразу пишутся с использованием POM, новый рефакторинг не требуется.

Что это дало бизнесу: цифры и эффекты

Да, внедрение POM потребовало около двух человеко-месяцев на 95 тестах, но уже через несколько циклов разработки стало ясно, что это решение полностью себя оправдало: около 70% тестов состоит из вызова уже известных методов и занимает около 4 часа на каждый тест, в том время как раньше требовалось 12 часов.

Комбинация POM и Cypress показала себя рабочим решением.

Теперь у нас есть:

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

Заключение и рекомендации

Переход на Page Object Model — это не «переписывание кода ради красоты». Это инвестиция в скорость и стабильность процесса тестирования. Если вы замечаете, что поддержка автотестов отнимает больше времени, чем их создание, а новые инженеры не могут быстро разобраться в кодовой базе — вероятно, пришло время задуматься об архитектуре.

С чего начать?

1. Выделите самые «хрупкие» и часто дублирующиеся части ваших тестов.

2. Создайте первый Page Object для самой проблемной страницы.

3. Рефакторите постепенно, покрывая новые функциональности уже по новым стандартам.

Уже через несколько итераций вы заметите, как время на рутину сокращается, а ценность автотестов для бизнеса — растет.

От «спагетти-кода» к чистым сценариям. Как Page Object Model помог нам преодолеть техдолг в автотестах