Как стать автором
Обновить
34.95
Рейтинг

Внедрение E2E-тестирования с Puppeteer и Jest

ReksoftРазработка веб-сайтовJavaScriptGoogle ChromeТестирование веб-сервисов

Привет, Хабр!

Хотим поделиться краткой историей о том, как мы на одном из проектов «Рексофт» пришли к написанию автотестов, и почему сделали акцент именно на e2e-тестах.

Речь пойдет о работе с порталом крупного федерального заказчика, работающего в сфере B2B и B2C, имеющего серьезный трафик из всех регионов. Сайт писал не «Рексофт». Ресурс попал к нам на поддержку какое-то время назад. Изначально проект содержал довольно много легаси кода, тестов не было, как и документации. Требовалось сделать редизайн по новым макетам, параллельно расширяя существующую функциональность. Обычная история.

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

Перед выбором подхода к автотестам классифицировали баги по типу: их большая часть касалась именно бизнес-логики (Javascript). Багов, связанных с кроссбраузерностью или вёрсткой, было не очень много.

Итак, цель была поставлена — автоматизировать проверку бизнес-логики, т.е. заполнение и отправку форм, работу слайдеров и т.д.

В качестве базового фреймворка для тестов был выбран Jest, а для имитации действий пользователя — Puppeteer. Последний выбрали благодаря тому, что он поддерживается Google и имеет отличную документацию. Нам было вполне достаточно тестов в одном браузере (Chrome) (хотя, есть инструменты, позволяющие с помощью Puppeteer запускать тесты и в других браузерах, например, Firefox и IE). Playwright тогда ещё не было, а Selenium, чисто субъективно, казался более сложным в развертывании.

Далее кратко опишу преимущества и недостатки e2e-тестов.

Недостатки e2e-тестов

Относительно высокая сложность написания. Нужно обладать определёнными навыками, чтобы написать компактный и легкочитаемый e2e-тест.

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

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

Ускорить прохождение тестов можно, запуская их параллельно. В этом поможет Browser Context в Puppeteer.

Пример конфига Jest + Puppeteer

Далее, вместо

page = global.__BROWSER__.newPage()

Используйте

newContext = await global.__BROWSER__.createIncognitoBrowserContext();
page = await newContext.newPage();
// example.spec.js
describe('[Домашняя страница]', () => {
  let page;

  beforeAll(async () => {
    const newContext = await global.__BROWSER__.createIncognitoBrowserContext();
    page = await newContext.newPage();

    await page.goto('https://google.com');
  });
  
  it('Страница должна называться "Google"', async () => {
    await expect(page.title()).resolves.toMatch('Google');
  });
});

Число параллельно запускаемых тестов в Jest регулируется флагом --maxWorkers.

«Хрупкость» e2e-тестов. Что я имею ввиду? Случай, когда тест падает без видимых на то причин, а при повторном запуске успешно выполняется, или же когда к падению теста приводит незначительное изменение в верстке. С хрупкостью тестов можно бороться с помощью автоматического перезапуска теста после падения. Помогут в этом раннер jest-circus и параметр retryTimes. Это практически полностью решает проблему “ложных” падений тестов.

Преимущества e2e-тестов

Гарантии. С e2e-тестами вы получаете определенные гарантии того, что система в целом работает корректно. Юниты такой гарантии не дают. Разумеется, это не значит, что вы получаете 100% гарантию того, что у вас работает абсолютно всё. Но вы будете уверены, что по крайней мере протестированные сценарии точно работают.

Снижение рабочей нагрузки. Без тестов разработчик вынужден думать — «как бы чего не сломать». Ведь не прокликивать же весь проект после очередного коммита с правками! С тестами вы узнаете о поломке еще до того, как код будет залит на стенд.

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

Ускорение рефакторинга. При рефакторинге js, e2e-тесты не придется переписывать. Да и рефакторинг в вёрстке тоже редко приводит к их переписыванию.

Нет зависимости от кодовой базы и js-фреймворка. Вы можете написать e2e-тесты даже к легаси коду, что поможет быстрее его отрефакторить. При этом вы практически не зависите от js-фреймворка, т.к. в тестах оперируете только сущностями браузера.

Лайфхаки

1. Для ускорения написания первых тестов можно записывать действия пользователя с помощью Headless recorder или с помощью встроенных в Chrome инструментов.

2. Если требуется проверить несколько наборов данных в рамках одного кейса и руки тянутся написать for внутри теста, используйте jest-each. Эта библиотека позволит прогнать несколько наборов данных в одном кейсе, сохранив читаемость кода:

each`
 url | selector | expectedIsVisible
 ${'/page1.html?land'} | ${'.js-order-button'} | ${true}
 ${'/page1.html'} | ${'.js-order-button'} | ${false}
 ${'/page2.html?land'} | ${'.js-order-button'} | ${true}
 ${'/page2.html'} | ${'.js-order-button'} | ${false}
`.it('Отображение кнопок заказа на странице $url', async ({ url, selector, expectedIsVisible }) => {
 await page.goto(`${SERVER_URL}${url}`, {
   waitUntil: 'networkidle2',
   timeout: 0
 });
 expect(await isVisible(page, selector)).toEqual(expectedIsVisible);
});

3. В случае возникновения ошибок, puppeteer не всегда корректно подсвечивает строку с ошибкой. Поэтому следует проверить код перед ошибочной строкой, часто ошибка кроется именно там.

4. Puppeteer позволяет запускать браузер с различными флагами, что иногда очень полезно (chrome://flags/). Ниже пример запуска браузера с отключенным флагом SameSite by default cookies

puppeteer.launch({
 headless: true,
 slowMo: 80,
 args: [
   '--disable-features=SameSiteByDefaultCookies'
 ]
});

В качестве заключения

Написание e2e-тестов занимают около 5-10% от времени написания фичи. На фиксы багов уходило сильно больше времени, так что оно того стоило. Несмотря на ряд недостатков, e2e-тесты позволяют значительно ускорить процесс разработки и обрести уверенность в том, что основная функциональность системы работает.

Разумеется, при внедрении e2e-тестов для фронтенда необходимо учитывать специфику вашего проекта. Спасибо за внимание!

Теги:jestpuppeteere2eтестированиеавтоматизация тестированияразработка
Хабы: Reksoft Разработка веб-сайтов JavaScript Google Chrome Тестирование веб-сервисов
Всего голосов 5: ↑4 и ↓1 +3
Просмотры1.8K

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
www.reksoft.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре