UI-тестирование с Puppeteer: практическое руководство

В чём UI-тестирование с Puppeteer действительно хорошо

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

• Скрейпинг и автоматизация. Значительная часть применений Puppeteer вообще не связана с тестированием — и с этими задачами он справляется отлично.

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

Три статьи расходов на браузерный набор тестов

• Селекторы ломаются. Редизайн, который ничего не меняет функционально, окрашивает весь набор в красный. Именно сюда и уходит бóльшая часть времени на поддержку.

• Ожидания — тонкая материя. Фиксированные задержки замедляют прогон и всё равно дают нестабильность; правильное ожидание требует понимать, чего именно ждать. Большинство нестабильных тестов растут отсюда.

• Покрытие пишется руками. Вы покрываете то, что кто-то написал, — то есть сценарии, показавшиеся интересными, а не те, которые ломаются.

Как решить, что автоматизировать

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

Второй фильтр — как часто это меняется. Сценарий, который меняется каждый спринт, обойдётся в поддержке дороже, чем принесёт пользы. Покройте его позже, когда он устоится.

Три привычки, которые экономят больше всего времени

• Используйте стабильные атрибуты. Отдельный тестовый атрибут вместо CSS-пути. Одно это изменение убирает бóльшую часть поломок при редизайне.

• Ждите состояния, а не времени. Ждите появления элемента или ответа, но никогда — заданного числа миллисекунд.

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

Где уместна проверка на основе намерений

Ломкость селекторов и написанное вручную покрытие — проблемы структурные, а не те, что лечатся дисциплиной. Шаг, выраженный как намерение, переживает редизайн, который убивает селектор; а покрытие, построенное по вашему продукту, а не по чьей-то памяти, включает сценарии, которые никто бы не написал.

Это не аргумент против Puppeteer — он остаётся правильным инструментом для прямого управления браузером. Это аргумент против того, чтобы писать вручную всю широту покрытия.

Если вы предпочитаете ничего не устанавливать, панель управления делает то же самое. Всё остальное, что умеет командная строка, описано в репозитории CLI.

Три вещи, которые делают скрипт на Puppeteer хрупким

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

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

Вторая — фиксированные ожидания. Задержка, достаточно длинная, чтобы быть надёжной в медленный день, — это задержка, которую вы платите в каждый быстрый день, и в самый медленный она всё равно не спасёт. Ждите элемент, ответ или смену состояния.

Третья — проверка того, что вы только что сделали. Нажать «Сохранить», а затем убедиться, что кнопка «Сохранить» на месте, не доказывает ничего. Проверка должна быть тем, что становится истинным только при реально завершённой операции, а это обычно значит — запросить объект обратно.

Запускайте на каждое изменение

Если пайплайном владеет другая команда, то GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда ваша сборка сообщает, что новая версия развёрнута. Если же вы хотите видеть проверку прямо в репозитории, шаг GitHub Actions сделает то же самое.

Какое место TestSprite занимает рядом с Puppeteer

Puppeteer остаётся для прямого управления браузером: скриншоты, PDF, перехват сетевых запросов, скрейпинг. TestSprite берёт на себя ту часть, которая не масштабируется временем автора: решать, что покрывать, и поддерживать это в рабочем состоянии.

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

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