Миграция автотестов с Cypress на Playwright

Делимся свои опытом: как мы обеспечили быструю и безопасную миграцию с одной технологии на другую с использованием ИИ.

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

Параллельно изменился пользовательский трафик: заметно выросла доля Safari на планшетах. Но автотесты были написаны на Cypress, а он технически не позволяет полноценно проверять работу в Safari на разных устройствах.

Все свелось к трем задачам:

• сохранить накопленные наработки, 

• сократить время выполнения тестов, 

• добавить поддержку планшетов и браузера Safari. 

Под эти требования лучше всего подошел Playwright: он остается в экосистеме TypeScript и имеет похожую структуру тестов. При этом важно было организовать «мягкую» миграцию – переносить тесты постепенно, не останавливая разработку.

Почему не руками?

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

Три этапа миграции

1) Выстраиваем архитектуру будущих тестов

Первым шагом стала разработка архитектуры будущих API-тестов. Мы решили сохранить подход, к которому команда привыкла в Cypress -структуру в стиле Page Object Model, о которой мы уже рассказывали раньше.

• На верхнем уровне появился универсальный ApiClient.ts с базовыми запросами и параметрами.

 Пример:

• Для каждого бизнес-модуля создан отдельный файл (например, AddressBookMS.ts) с методами работы с сервисом и входными данными. 

Пример:

• Сценарии остались в привычных спецификациях (например, widgetContacts.spec.ts), которые покрывают регрессию.

Пример:

Структура четко разделяет тесты и объекты тестирования, позволяя быстро корректировать любой из элементов.

Если оставить «все в одном месте», как часто бывает при работе с новым инструментом, проект быстро становится неуправляемым. Такое разделение распределяет зоны ответственности: изменения в API вносятся в одном файле, а тесты при этом не ломаются. Это снизило риски при миграции и сделало код понятным даже новым участникам команды.

2) Планируем структуру сценариев

В Cypress используются глобальные функции describe и it, которые делают структуру тестов понятной и привычной. В Playwright аналогичная структура достигается с помощью test.describe и test, которые эмулируют это поведение. Асинхронность запросов, привычная в Cypress, компенсировалась дополнительными параметрами Playwright без потерь в скорости.

Пример

Для команды это означало минимальный «когнитивный барьер»: структура выглядела знакомо, и старые Cypress-тесты, и новые Playwright-сценарии имели единый стиль.

3) Используем ИИ для переноса атомарных тестов

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

Для пробы мы запустили небольшую модель на локальных машинах инженеров. Однако мощности не хватало, и для полноценной работы мы развернули на сервере более производительную модель Qwen3-32B.

Важно: ИИ не может «сам переписать тесты» – без понимания бизнес-контекста и участия инженеров он генерировал код, который не работал или не соответствовал задачам. Зато как ассистент он снимал рутину и ускорял работу QA инженера благодаря вспомогательным функциям:

• помогал адаптировать отдельные конструкции из Cypress в Playwright, 

• подсказывал варианты импорта или структуру тестов, 

• ускорял работу над повторяющимися задачами. 

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

Результаты

• Первый модуль: ~7 часов (включая настройку окружения и обучение).

• Последующие тесты: ~1 час на тест по мере накопления опыта.

• Общее время миграции: Уложились в запланированные сроки без срыва релизов.

• Безопасность: Ни один тест не покинул периметр компании.

Главные технические итоги:

1. Время прогона упало с 10+ до 3 часов за счет оптимизаций Playwright и параллельного запуска.

2. Появилась поддержка Safari и мобильных устройств — покрытие стало полноценным.

3. Архитектура стала чище — разделение слоев (клиент → сервисы → тесты) повысило поддерживаемость.

Заключение

Миграция автотестов — это стратегический проект, требующий:

1. Четкой архитектуры на старте.

2. Постепенного подхода без остановки работы.

3. Правильных инструментов (в нашем случае — локальный ИИ как ассистент).

4. Инвестиций в обучение команды.

Playwright повысил скорость, покрытие и поддерживаемость наших автотестов. А локальный ИИ доказал, что может быть эффективным помощником в рутинных задачах без угрозы безопасности.

 А вы сталкивались с миграцией автотестов? Какой подход использовали — полный рерайт, постепенный переход, конвертацию? Доверяете ли ИИ в таких задач