Тестирование React. Часть 2: Playwright
Всем привет. Я - Петр Цой. Ищу первую работу на React. В качестве моего резюме выступает сайт petrtcoi.com. Ссылка на GitHub.
В предыдущей статье я рассмотрел unit-тесты моего приложения с помощью библиотеки @testing-library. Здесь опишу для чего и как применяю end-to-end тесты. Использую библиотеку Playwright.
Зачем
Фреймворк Playwright эмулирует работу браузеров, используя их же движки. Если testing-library готовит упрощенную версию HTML документа, то Playwright отрисовывает документ также, как он будет отрисовываться у посетителей сайта (причем может это сделать для разных устройств).
Если в случае с @testing-library ряд функций, завязанных на CSS, мы могли проверить только по косвенным признакам. То теперь мы можем протестировать все напрямую.
Настройка
Для настройки я следовал стандартным инструкциям, размещенных на сайте фреймворка. После чего немного настроил его под себя.
Во-первых, поменял локации стандартных папок в файле playwright.config.ts.
Таким образом, тесты переместились в папку src. В этом же файле убрал комментарии для нескольким мобильных устройств. Чтобы работа сайта проверялась и на них: Pixel 5 и iPhone 12.
Во-вторых, прописываем скрипты в package.json
Первая команда запускает тест. Вторая запускает тест с обновлением сохраненных скриншотов.
В-третьих, на случай роста проекта и появления в нем новых страниц, я сразу добавил объект для хранения адресов страниц. Это упростит читаемость и поддержку кода.
Также добавил файл с константами
Проверка работы бокового меню
Видимость и анимация бокового меню реализованы полностью через CSS: на самом компоненте меню установлен атрибут data-state-popupmenu-status={ props.menuStatus }, при переключении которого боковое меню или "выскакивает" или "скрывается".
Код CSS выглядит следующим образом:
При тестировании данного компонента с помощью @testing-libraryвсе, что мы могли сделать, это проверить значение атрибута data-state-popupmenu-status и положиться на то, что CSS отработает смену его значения как требуется.
Благодаря Playwright мы получаем возможность как проверить, находится ли меню в зоне видимости. Для этого создадим вспомогательную функцию:
Функция берет значения размеров экрана props.page.viewportSize()и координаты объекта pops.element.boundingBox(), затем просто проверяет, входит ли элемент в границы экрана или нет.
Здесь я проверяю только горизонтальную ось. Поэтому и функция называется так замысловато.
Файл с тестом этой функции выглядит следующим образом. Сначала загружаем страницу и проверяем, что все требуемые элементы на ней удалось найти.
После этого добавляем, собственно проверку, где находится наше меню: за экраном или на нем. Из-за того, что появление и исчезновение меню происходит не моментально, я добавил небольшие паузы: await page.waitForTimeout(changeThemeDuatationMs).
Проверка смены темы сайта и snapshot-тесты
В прошлой статье, при составлении unit-тестов, мы проверили лишь сам вызов функции, меняющей тему, и убедились, что в нее передаются верные аргументы. Но, собственно, смену требуемого атрибута в теге и, тем более, изменение цветовой схемы на сайте, мы проверить не могли.
Как работает смена темы
Цвета на сайте задаются через CSS-переменные и выглядят они так:
Смена темы происходит через вспомогательную функцию:
Как проверяем
Первый шаг, как обычно, загружаем страницу и убеждаемся, что на ней ей все, что должно быть:
Далее собственно тесты. Первая группа проверяет, что в тег ставится нужный атрибут.
Вторая группа тестов делает снимки экранов и, при следующем запуске тестов, проверяет, произошли ли какие-либо изменения. Если да, то генерирует отдельные изображения, где подсвечивает изменения. Тесты выглядят так:
Здесь я напрямую указал названия изображений, чтобы было проще ориентироваться. Playwright генерирует изображения и включает название в свои названия:
Теперь можно просто пройтись по ним и посмотреть, выглядит ли сайт, как ожидалось. Если все в порядке, то можно в будущем полагаться, на этот тест, что все работает верно.
Побочным эффектом данного теста является еще и проверка работы бокового меню.
Также, наличие snapshot-теста, в данном случае ставит под вопрос, насколько нужен был предыдущий тест, который проверял тег : он проверял внутренности кода не давая, при этом, никакой информации о конечном результате.
Но, так как он уже написан и смена механизма смены темы не предвидится, то решил его оставить. Возможно, в будущем он окажется полезным.
Заключение
Здесь я рассмотрел работу с фреймворком Playwright. Написание тестов на нем ненамного сложнее, чем на @testing-library. При этом сами тесты выходят более надежными, так как проверки осуществляются в условиях максимально приближенным к реальным.
Snapshot-тесты настраиваются очень просто но, при этом, дают возможность быстро оценить работу сайта "в целом": сменилась ли тема, не накосячили ли мы с CSS, отработала ли логика и т.д. В следующей статье я опишу проверку сайта с использованием Storybook, но возможности Playwright в этой части мне показались более подходящими.
В то же время нужно отметить, что e2e тесты работают заметно медленнее простых unit-тестов и написание кода в стиле TDD мне показалось на них затруднительным. Их область применения - это проверка работа сайта на общем уровне и, как в случае с , дополнительное тестирование там, где проверка unit-тестов может вызывать сомнения в надежности.