Мир Javascript стремительно растет с добавлением новых библиотек и фреймворков каждый день. Как сообщалось, только на npm каждый день добавляется почти 500+ пакетов, и эта тенденция далека от изменения! В этой быстро развивающейся экосистеме сложно оставаться в курсе последних, удобных и эффективных фреймворков. Я столкнулся с аналогичной ситуацией, и мне пришлось провести исследование, чтобы выбрать фреймворк для сквозного тестирования, который лучше всего подходит для нашего веб-приложения. Этот пост является результатом этого исследования, и я надеюсь, что вы сочтете его полезным при выборе того, что лучше всего подходит для вашего javascript-приложения.

Что считается сквозным тестированием?

Давайте сначала разберемся, что такое сквозное тестирование. В некоторых ситуациях это также называется функциональным тестированием или интеграционным тестированием. Но охватываемые варианты использования варьируются в зависимости от организации и команды. В контексте современных модульных веб-приложений независимые компоненты пользовательского интерфейса можно рассматривать как строительные блоки. Можно провести модульное тестирование этих отдельных компонентов. Интеграционное тестирование может проводиться с несколькими компонентами, объединенными для тестирования конкретного потока или функции. Однако сквозное тестирование воспринимается как тестирование точно так же, как то, как пользователь будет взаимодействовать с приложением. Следовательно, на выбор структуры сквозного тестирования влияет множество факторов.

Предыстория: веб-приложение в центре внимания

Как я описывал ранее, эта статья является частью исследования, которое мне пришлось провести при выборе фреймворка для нашего веб-приложения. Я считаю, что краткая справка о техническом стеке этого веб-приложения поможет лучше понять следующую информацию. Наше веб-приложение было создано на ReactJS. Он обслуживался с использованием NodeJS. Большинство веб-приложений были на стороне клиента, и поэтому сквозное тестирование в среде , подобной браузеру, было чрезвычайно важным. Мы использовали Jest для модульного тестирования.

Какие фреймворки были охвачены?

В этом исследовании оцениваются различные тестовые среды, которые можно использовать для сквозного тестирования для веб-приложений на основе javascript. Он включает функции различных фреймворков для тестирования, в том числе - CasperJS, Protractor, NightWatch, TestCafe, WebDriverIO, Puppeteer и Jest.

В следующей таблице приведено сравнение важных функций в вышеперечисленных фреймворках.

Давайте рассмотрим плюсы и минусы каждого из них.

Шутка

Плюсы

  • Поддерживает синтаксис в стиле мокко
  • Поддерживает тестирование снимков
  • Настоятельно рекомендуется для приложения React
  • Управляется FB и активным сообществом
  • Легко интегрировать с Puppeteer

Минусы

  • По умолчанию не обеспечивает функциональное тестирование пользовательского интерфейса.

Полезно знать

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

Casper JS

Плюсы

  • Поддержка ES6, CoffeeScript
  • Использует PhantomJS
  • Нет необходимости в реальном браузере

Минусы

  • Использует безголовый подход (тоже профессионал)
  • Синтаксис отличается от Mocha (может иметь поддержку фреймворка Mocha)
  • Ожидание элемента явное

Полезно знать

  • Требуется Python

Транспортир

Плюсы

  • Использует настоящий браузер
  • Хорошая поддержка селеном
  • Использует код стиля мокко
  • Код похож на код, используемый в Java Selenium API.
  • Ожидание элемента неявно

Полезно знать

  • Требуется JDK

Ночной дозор

Плюсы

  • Легко читаемый код
  • Автоматическая повторная попытка при неудачных тестах
  • Позволяет модульный подход для повторного использования кода
  • Гибкость - позволяет настраивать команды
  • Мощный синтаксис позволяет быстро писать тесты с использованием селекторов css или XPath.

Минусы

  • Требуется явное ожидание
  • Конфигурации длинной среды
  • В коде не используется стиль мокко.

Полезно знать

  • Требуется Selenium JAR (должен находиться в той же папке, что и исходный код теста)
    (Требуется автономный сервер Selenium)
  • Зависимость драйвера Chrome (должна находиться в той же папке, что и исходный код теста)
  • Использует API WebDriver

TestCafe

Плюсы

  • Минимальные конфигурации
  • Поддержка ES6 / ES7
  • Автоматическое ожидание
  • Нет зависимости от браузера или плагина
  • Открытый источник

Минусы

  • Требуется браузер
  • Нет дружественного к Mocha синтаксиса

Полезно знать

  • НЕ использует веб-драйвер или селен в качестве базовой платформы

Кукольник

Плюсы

  • Управляется Google
  • Поддерживает тестирование пользовательского интерфейса и многие другие функции
  • Интеграция с Jest
  • Поддерживает как безголовый, так и полноценный хром

Минусы

  • Не поддерживает другие браузеры, кроме Chrome.

Заключение

Как я описал ранее, выбор одного из вышеперечисленных действительно зависит от индивидуальных требований проекта. Вам нужно ответить на такие вопросы, как «Достаточно ли будет протестировать только на Chromium или нужно протестировать весь возможный стек браузера?», «Будет ли моя инфраструктура CI поддерживать все системные зависимости и внешние библиотеки?», «Нужна ли мне полная браузерная версия? подойдет выполнение теста или безголовый тест? »,« Будет ли хорошо управлять разными фреймворками для модульного и сквозного тестирования? »,« Насколько сложно будет изучить и настроить новый фреймворк? (Предполагая, что вы уже используете некоторые из них для модульного / интеграционного тестирования) »,« Насколько важно обеспечить покрытие кода? » и «Потребуется ли вам когда-нибудь тестирование снимков?»

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

Я надеюсь, что эта статья станет хорошей отправной точкой в ​​вашем путешествии по открытию сквозного фреймворка следующего поколения для вашего приложения JavaScript.

Ваше здоровье!

Ссылки