В начале этого года я писал клиентские тесты с использованием Selenium в своей компании. Это отлично подходит для разработчиков, которые пишут в основном на Scala. Проблема в том, что изучение Scala и Selenium — это высокий стандарт для разработчиков при написании сквозных тестов. У нас много разработчиков, которые пишут почти исключительно на TypeScript. Как новичок в Scala, тестирование новой функциональности на стороне клиента настолько сложно, что тесты обычно не пишутся.
Когда я открыл для себя Puppeteer, он показался мне подходящим инструментом для решения этой проблемы. Разработчики могут писать тесты на TypeScript, языке, с которым они более знакомы. Мы уже используем Jasmine для написания модульных тестов, поэтому возможность создавать тесты Puppeteer с помощью Jasmine — это явное преимущество. Разработчики также могут подключаться к Chrome DevTools во время выполнения тестов, чтобы использовать знакомый им отладчик. Все эти функции отлично подходят для уменьшения условий написания тестов на стороне клиента. Puppeteer также имеет некоторые преимущества перед Selenium.

Более простое выполнение JavaScript

Отличительной особенностью Selenium и Puppeteer является возможность запускать JavaScript в браузере. Варианты использования этой функции практически безграничны, и использовать ее в Puppeteer практически не составляет труда. Сравните следующие два фрагмента кода: Скала + Селен

val evalResult = Json.parse(driver.executeAsyncScript(“””
    var callback = arguments[arguments.length - 1];
    asyncFunction().then(callback);
“””).asInstanceOf[String])

TypeScript + Puppeteer

const evalResult = await page.evaluate(() => asyncFunction());

Версия TypeScript может быть проще и имеет некоторые дополнительные преимущества. Во-первых, версия TypeScript автоматически обрабатывает исключения. Если AslenFunction не работает в версии Selenium, ошибки нет, вместо этого истекает время ожидания. Вы можете и, вероятно, должны создать функцию-оболочку, чтобы упростить вызов JavaScript и правильно обрабатывать ошибки, если вы используете Selenium. Однако, поскольку базовая реализация уже проще, Puppeteer — лучший выбор. Нет необходимости изменять интерфейс.
Версия Puppeteer также имеет преимущество проверки типов TypeScript. Вы можете объявить функции и переменные, используемые внутри вычисления, и если у вас есть ошибки синтаксиса или типа, TypeScript обнаружит эти ошибки. В Selenium вы не поймаете ошибки, пока не попытаетесь запустить тест.
В основе этих преимуществ лежит то, что тестовый драйвер говорит на том же языке, что и браузер. Это делает соединение двух более плавным. В качестве примечания: вы можете написать тесты Selenium на TypeScript и добиться аналогичной бесшовной реализации оценки, но это не вариант для нашего кода Scala, поэтому я указываю это как причину, по которой я хотел бы переключиться на Puppeteer.

сетевой перехват

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

Тестовая обработка неудачных запросов

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

Имитация сторонних сервисов

У меня есть непосредственный опыт перехвата сети в этой категории. Мы хотим написать несколько автоматических тестов для блоков Salesforce. В чем проблема? Наш подключаемый модуль Salesforce основан на вызове Salesforce API. Если мы напишем тесты для входа в существующую учетную запись Salesforce для запуска этих тестов, мы столкнемся с некоторыми проблемами: нам придется полагаться на тестовую машину с надежным подключением к Salesforce, а изменение графического интерфейса Salesforce приведет к тому, что наши тесты перестанут работать. внезапный сбой без каких-либо ошибок, Salesforce может определить, что мы входим в систему как бот, и установить CAPTCHA или потребовать двухэтапную проверку. Удивительно. Кукольник решил эту проблему для нас. Нам удалось написать фиктивный API Salesforce, который работал локально. Любой запрос к Salesforce перехватывается Puppeteer, и вместо него возвращаются поддельные данные.

Протестируйте автономный режим

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

отладка

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

Один браузер, один язык

Это звучит как недостаток. Если бы я писал статью о том, почему Selenium лучше Puppeteer, я бы определенно указал, что Selenium дает вам больше возможностей для выбора языка, который вы хотите использовать, и, что более важно, Selenium позволяет запускать тесты в нескольких браузерах. Так почему я должен давать Puppeteer дополнительные баллы за отсутствие этих функций? Потому что эти функции требуют оплаты.
При поиске примеров кода на Selenium вы часто найдете примеры на другом языке. Вы можете поискать в Интернете и найти хорошие руководства по использованию Selenium или хороший фрагмент кода, показывающий, чего вы хотите достичь, но они могут быть на языке, который вы не используете и с которым не знакомы.
Кроме того, обещание Selenium «написать один раз, запустить в любом браузере» не всегда выполняется в реальном мире. По какой-то причине некоторые тесты будут проходить в одном браузере, а не в другом по непонятной причине. Ошибки в разных драйверах браузера могут помешать надежному выполнению тестов во всех браузерах. Если вы готовы выполнить дополнительную работу, вы можете запускать тесты в нескольких браузерах, но вам нужно ориентироваться только на один браузер, что может значительно упростить вашу разработку.

Итак, вы должны выбрать селен вместо Puppeteer?

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

после просмотра

Ставьте лайк, чтобы больше людей увидело этот контент
Обратите внимание на паблик «Новое сообщество фронтенда» и наслаждайтесь первыми статьями!
Сосредоточьтесь на преодолении технической трудности переднего плана каждую неделю.