Напишите свои собственные тестовые сценарии E2E для Playwright & Puppeteer

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

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

Используйте рекордер

Рекордер — это инструмент, который может записывать ваши действия в браузере и превращать эти действия в полноценный сценарий автоматизации. Таким образом, вы можете начать программировать свой тест, просто пройдясь по пользовательскому потоку, как это сделал бы пользователь.

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

Я считаю тестовые регистраторы довольно полезными по нескольким причинам:

1. Больше не искать селекторы. Нет смысла искать селекторы самостоятельно, если вы можете автоматизировать работу. Лучшие рекордеры используют логику селекторов, которая даст вам стабильные селекторы, вместо того, чтобы пытаться перечислить каждое имя div и класса на пути к вашему элементу. (Мы также поговорим о селекторах позже!)

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

1. Лучшие практики встроены. Хотя регистраторы не могут генерировать идеальный код, в них будут встроены лучшие практики. Вместо того, чтобы беспокоиться об использовании «заполнения» вместо «типа» или вспоминать, как ждать текста в Puppeteer, вы можете просто позволить рекордеру сгенерировать код, соответствующий передовым практикам, чтобы вы могли сосредоточиться на остальной части вашей работы. .

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

Вот несколько рекордеров, которые могут помочь вам начать работу:

• DeploySentinel Recorder: расширение для Chrome/Firefox, которое генерирует скрипты Cypress/Playwright/Puppeteer (Отказ от ответственности: я являюсь одним из авторов, но только потому, что хотел создать наиболее точный Регистратор в наличии)

• [Playwright Codegen] (https://playwright.dev/docs/codegen): инструмент командной строки, включенный в Playwright.

• Puppeteer Chrome DevTool Recorder: встроенный в Chrome рекордер для Puppeteer.

• Безголовый рекордер: расширение Chrome, которое может автоматизировать некоторые более простые действия.

Используйте стабильные селекторы

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

Особенно, если в вашем проекте используется что-то вроде Tailwinds, styled-components или даже JS-фреймворк, такой как React или Vue, которые используют асинхронную логику для рендеринга элементов, вам может быть трудно понять, как надежно настроить правильный элемент.

Первое решение: идентификаторы тестов

Лучший способ борьбы с этими проблемами — явно ввести стабильный селектор для элементов, которые вы хотите протестировать, и ничто не сравнится со стабильностью, как введение тестовых идентификаторов в ваше приложение.

Концепция очень проста: для элементов, с которыми вам нужно взаимодействовать, добавьте атрибут data-test-id="my-element" к элементу HTML. В ваших сценариях автоматизации вы можете легко настроить таргетинг элемента с помощью

await page.click('[data-test-id="my-element"]');

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

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

Второе решение: селекторы специальных возможностей

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

Обычно вы увидите такие атрибуты, как «aria-label», «alt» или «title» для элементов, с которыми вы хотите взаимодействовать. Эти атрибуты, как правило, более стабильны, чем классы CSS, и могут служить хорошей временной мерой, пока вы не сможете реализовать идентификаторы тестов для элементов, которые необходимо протестировать.

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

await page.click('[alt="Основной логотип"]');

Последнее решение: селекторы текстового контента

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

На первый взгляд это может показаться невероятно хрупким предложением. На самом деле это может быть для некоторых элементов, но для других это может быть лучшее доступное стабильное решение. Можете ли вы вспомнить, когда ваша команда в последний раз обновляла текст кнопки «Войти» в вашем приложении?

Для элементов с нединамическим текстовым содержимым, обычно кнопок или заполнителей ввода, текстовое содержимое может быть довольно надежным способом нацеливания на элементы.

К счастью, в Playwright невероятно легко ориентироваться на элементы по тексту, например:

page.click('text=Войти');

В Puppeteer вам нужно погрузиться в XPaths для нацеливания элементов по тексту:

await page.waitForXPath('//*[содержит(., "Войти")]');

const [элемент] = await page.$x('//*[содержит(., "Войти")]');

ждать элемент.клик();

Автоматизировать выбор селектора

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

Перевернуть функции отладки

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

Инспектор драматургов и следопыт

С Playwright невероятно легко добавить PWDEBUG=1 перед вашим сценарием, чтобы открыть [Инспектор драматургов] (https://playwright.dev/docs/inspector), где он сможет пройти через все. делает очень подробно во время теста. Если есть шаг, с которым у вас возникли проблемы, вы можете добавить await page.pause(), чтобы приостановить тестовый запуск, чтобы вы могли проверить страницу в этот момент времени.

Если вы выполняете скрипт в удаленной среде, вы можете воспользоваться [Trace Viewer] от Playwright (https://playwright.dev/docs/trace-viewer), который записывает подробные журналы и снимки DOM до и после каждого действия.

Если вы используете DeploySentinel для запуска теста, трассировки Playwright фиксируются по умолчанию и доступны для просмотра в любое время для отладки тестовых прогонов.

Режим головы и замедленная съемка

В общем, вы также можете включить режим заголовка с включенным замедленным движением, чтобы визуально увидеть, что делает ваш скрипт. И Playwright, и Puppeteer поддерживают это всего двумя дополнительными строками кода. См. документы для Драматург и Кукловод здесь.

В DeploySentinel Recorder эти две опции всегда будут закомментированы, но вставлены как часть каждого созданного скрипта, чтобы упростить локальную отладку.

Включить инструменты разработчика Chrome

Наконец, если возникает проблема, требующая просмотра сетевых запросов или журналов браузера, вы можете настроить Playwright и Puppeteer на открытие панели инструментов разработчика Chrome при запуске браузера, чтобы все журналы и сетевые запросы автоматически записывались с самого начала. См. [Документацию Playwright] (https://playwright.dev/docs/debug#browser-developer-tools) здесь или раздел инструментов разработчика в [Документации по отладке Puppeteer] (https://github.com/puppeteer/puppeteer/ blob/main/README.md#debugging-tips).

Готово!

Я надеюсь, что этот список советов поможет вам в создании тестовых сценариев для Puppeteer или Playwright.

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

• Впервые опубликовано [здесь] (https://www.deploysentinel.com/blog/no-tears-guide-creating-e2e-tests-playwright-puppeteer)*