Особая благодарность Марте Бондире (фронтенд-разработчик в Typeform) и Хави Гомесу (QA-инженеру в Typeform) за их техническую помощь.

Комбинация CodeceptJS и Puppeteer - это простой, но мощный инструмент для автоматизации веб-тестирования. Действия и конфигурации легко программировать, но, что удивительно, открывающиеся возможности безграничны.

Как вы, возможно, знаете, довольно просто настроить несколько переменных помощника внутри файла codecept.json, например, userAgent, windowSize или base url среди других. Однако что произойдет, если мы захотим изменить определенные поля? Конечно, мы можем изменить их в codecept.json, но если кто-то, менее знакомый с рабочим процессом, захочет поднять его и запустить несколько быстрых тестов ... разве не было бы неплохо для этого человека автоматизировать его? Другими словами, установка, которая:

  • Позволяет автоматизировать повторяющиеся конфигурации
  • Доступно и понятно
  • Может быть легко изменен и обновлен

Несколько файлов конфигурации

Первое решение, которое приходит на ум, - создавать разные файлы конфигурации для каждого случая. Например, предположим, что мы хотим иметь две конфигурации для запуска непосредственно из интерфейса командной строки: одну для тестирования нашего веб-сайта в производственной среде, а другую - для промежуточных сред. Мы можем создать два JSON с производственными и промежуточными базовыми URL-адресами, сохранить их в каталоге с именем «config» и вызвать эти конкретные конфигурации после команды - config (или просто -c):

codeceptjs run — config ./config/production.json
codeceptjs run — config ./config/staging.json

Где эти JSON выглядят несколько близко к этому (с другим полем «url»):

{
  “tests”: “./*_test.js”,
  “timeout”: 10000,
  “output”: “./output”,
  “helpers”: {
    “Puppeteer”: {
      “windowSize”: “1200x800”,
      “waitForAction”: 2000,
      “url”: “https://staging.mywebsite.com",
      “show”: false
    }
  },
  “include”: {},
  “bootstrap”: false,
  “mocha”: {},
  “name”: “Desktop_MSF”
}

А теперь представьте, что, помимо этого, мы решили добавить пару размеров окон браузера и (почему бы и нет!) Бросить несколько пользовательских агентов из-за мобильных устройств. Мы можем создать полную конфигурацию для каждой комбинации случаев! Давай ... Сейчас 2018 год. Копирование и вставка выполняется уже более 30 лет. К сожалению, в какой-то момент после того, как накопилось 32 файла конфигурации, вы понимаете, что существует такое количество дублирования кода, что изменение чего-либо в настройке становится кошмаром.

Преодолеть добро

Вот где светит -override (или просто -o). Мы можем создать конфигурацию JSON по умолчанию и указать только то, что нужно изменить для каждого варианта. Например, в предыдущем примере у нас уже был базовый codecept.json по умолчанию, который тестирует наш веб-сайт в промежуточной среде, и теперь мы хотим запустить его в производственной среде (прямо из интерфейса командной строки). Для этого мы можем переопределить конфигурацию по умолчанию следующим образом:

codeceptjs run —-override ‘{ “helpers”: {“Puppeteer”: {“url: “https://www.mywebsite.com"}}}'

Красиво, избыточность убита! Но я знаю, о чем вы думаете: удобочитаемость исключена из уравнения. Не хорошо. Действительно, запись / чтение этих JSON может очень быстро стать неприятным при изменении более сложных вещей. Вот исправление: вместо того, чтобы писать его прямо в терминале, мы можем создать «дельта» JSON под названием production.json:

{
  "helpers": {
    "Puppeteer": {
      "url": "https://www.mywebsite.com"
    }
  }
}

А теперь пора запустить его, раскачивая колдовство:

codeceptjs run — override $(cat ./config/production.json | tr -d ‘ \t\n\r’)

$ (cat ./config/production.json | tr -d '\ t \ n \ r') в основном захватывает файл JSON и удаляет все пробелы, табуляции и разрывы строк, преобразовывая это уродливому JSON, который понимает - override:

  • tr указывает на замену или удаление определенных символов
  • -d указывает на удаление указанных символов
  • ‘\ T \ n \ r’ указывает на символы, которые мы удаляем: пробелы, табуляции, новые строки и «возврат каретки» (соответственно).

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

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

После инициализации пряжи в выбранном нами каталоге и установки всего, что нам нужно (в данном случае CodeceptJS и Puppeteer), будет создан файл package.json с информацией о проекте и его зависимостях. В этом JSON мы можем определять пользовательские команды внутри скриптов следующим образом:

{
  “name”: “my-tests”,
  “version”: “1.0.0”,
  “description”: “Testing suite for whatever”,
  “main”: “index.js”,
  “author”: “Typeform”,
  “license”: “MIT”,
  “dependencies”: {
    “codeceptjs”: “1.1.6”,
    “puppeteer”: “1.1.1”
  },
  “scripts”: {
    “test”: “codeceptjs run”,
    “test:800x600”: “codeceptjs run -o $(cat ./config/800x600.json | tr -d ‘ \t\n\r’)”
    “test:prod”: “codeceptjs run -o $(cat ./config/production.json | tr -d ‘ \t\n\r’)”,
    “test:galaxys5”: “codeceptjs run -o $(cat ./config/galaxys5.json | tr -d ‘ \t\n\r’)”,
    “test:galaxys5:prod”: “codeceptjs run -o $(cat ./config/galaxys5-prod.json | tr -d ‘ \t\n\r’)”,
  }
}

Это очень удобно, потому что запускать тесты в разных конфигурациях теперь так же просто, как набрать:

yarn test

or

yarn test:galaxy5:prod

or

yarn test:800x600

Это также совместимо с вашими любимыми опциями, такими как - steps или - verbose, непосредственно записанными в CLI рядом с пользовательской командой или внутри определения сценария, если вы предпочитаете. Мы могли бы стремиться к дальнейшим улучшениям, таким как создание только «атомизированных дельта» JSON, которые изменяют одно поле, а затем объединяют несколько из них, чтобы мы еще больше сокращали любые избыточности, но это выходит за рамки того, что нам сейчас нужно, поэтому мы оставим это здесь для Cегодня. В конце концов, мы достигли настройки, которая просто соответствует нашим первоначальным потребностям:

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

При использовании других помощников, таких как WebDriverIO или Protractor, несколько конфигураций также могут быть реализованы посредством многократного выполнения. Для получения дополнительной информации ознакомьтесь с этим руководством на веб-сайте CodeceptJS.

Спасибо за чтение! Мы рады поделиться своим опытом и помочь всем улучшить код.

Вы используете платформу разработчика Typeform? Хотели бы вы, чтобы он был размещен на нашем Портале разработчиков? Пожалуйста, поделитесь с нами!

И да… нанимаем!