В этом сообщении в блоге я объяснил, как фреймворк Cypress.io помог мне протестировать функцию «создание-бронирование» @ ANAROCK Technology.

Автоматизация тестовых примеров важна для каждой технической команды. Инженеры-испытатели очень стараются выявить проблемы до того, как продукт будет выпущен. Было бы нереалистично тестировать сотни тестовых примеров вручную после каждой отдельной фиксации на этапе разработки в методологии гибкого тестирования.
Когда накопилось множество тестовых задач, у нас появилась новая функция «создать бронирование», которая будет проверять ее. потребовалось довольно много повторных испытаний с несколькими наборами входных данных.
В нем четыре страницы и список из нескольких тестовых примеров, которые должен проверить QA. Вот несколько важных тестов:

  • На всех четырех страницах поля ввода принимают несколько типов данных. Поэтому мне пришлось проверить запрос от внешнего интерфейса и убедиться, что все ключи и значения соответствуют требованиям.
  • Вход пользователя в систему на основе ролей и автоматизация различных страниц в зависимости от разрешения пользователя, вошедшего в систему.
  • Добавление утверждений по запросу / ответу всех API (GET, POST & PATCH), используемых в этой функции.

Чтобы решить указанную выше задачу QA, я включил в короткий список следующие инструменты:

  • Селен
  • Транспортир
  • WebdriverIO &
  • Кипарис

Я изучил каждый инструмент на предмет всех плюсов и минусов. Чтобы охватить все вышеупомянутые случаи во внешнем интерфейсе, а также охватить тесты api-запрос-ответ в едином фреймворке, Cypress.io стал для меня лучшим вариантом. Вот что смог сделать фреймворк для тестирования Cypress, что заставило меня его использовать:

- Путешествие во времени: наведите указатель мыши на команды в журнале команд, чтобы точно узнать, что происходило на каждом этапе.

- Возможность отладки

- Автоматическое ожидание: не нужно добавлять в тесты ожидания или спящие режимы.

- Шпионы, заглушки и часы

- Контроль сетевого трафика

- Согласованные результаты

- Скриншоты и видео

Кроме того, Cypress - это среда для сквозного тестирования JavaScript, которую я предпочел. Более того, настроить Cypress легко и без проблем. Я задокументировал процесс установки, выполнив следующие быстрые шаги:

Установка Cypress
Измените текущий рабочий каталог на место, где вы хотите, и клонируйте свой проект.
В редакторе кода (код VS в моем случае) откройте только что созданный / клонированная папка проекта.

Я буду устанавливать Cypress через пряжу.

В терминале по новому пути к проекту выполните следующую команду, которая установит Cypress в ваш проект.

yarn add cypress -D

После завершения установки в папке проекта будет создан файл package.json.

Затем запустите Cypress с помощью следующей команды:

yarn cypress open

Взгляните на это окно, в котором мы будем создавать тестовые файлы в папке «integration».

Затем добавьте конфигурацию baseURL в файл cypress.json, как показано выше.

Добавление baseUrl позволило бы нам пропустить передачу baseUrl таким командам, как cy.visit() и cy.request(), как показано во фрагменте кода выше. Теперь мы готовы написать наши тесты, добавив их в папку интеграции.

Установка TypeScript

Я рекомендую писать тесты на TypeScript, так как он выполняет проверку типов и упрощает чтение и понимание кода. Выполните следующие команды, чтобы установить TypeScript:

yarn add — dev typescript

После завершения установки машинописного текста добавьте файл tsconfig.json в свою папку cypress, как показано выше.

Откройте только что созданный файл tsconfig.json и добавьте эту конфигурацию. «Типы» сообщают компилятору TypeScript включать только определения типов из Cypress. Вы можете соответствующим образом редактировать lib / types и т. Д.

Затем вам нужно будет перезапустить сервер TypeScript вашей IDE. Откройте палитру команд (Mac: cmd + shift + p) и выберите параметр «TypeScript: Restart TS server.».

Чтобы добавить пользовательские команды к объекту cy, вам нужно вручную добавить их типы, чтобы избежать ошибок TypeScript.

Скажем, если вы добавите пользовательскую команду (cy.createBooking в моем случае) в свой файл поддержки следующим образом,

затем вы должны создать новый файл определений TypeScript рядом с файлом поддержки (в cypress / support / index.d.ts) и добавить createBooking () в свой глобальный интерфейс Cypress Chainable, как показано ниже.

После этого процесса, когда вы пишете тесты в папке интеграции и вызываете пользовательскую команду cy.createBooking («phoneNumber») , компилятор TS не должен жаловаться на неизвестный метод.

После настройки Cypress для моего проекта, вот как выглядела моя структура проекта, где я написал несколько пользовательских тестов в файле create-booking.spec.ts и определил все свои повторно используемые команды в cypress. /support/commands.ts по мере его загрузки перед оценкой любых тестовых файлов.

Я написал свои функции «createBooking & login» здесь, в файле commands.ts, как показано ниже. Хорошей практикой является запись всех ваших многоразовых функций здесь, в этом файле, например: - clickLink / checkToken / getSessionStorage / login / logout и т. Д.

Как показано в образце структуры формата на снимке экрана, я написал функцию входа в систему для разных типов ролей пользователей в моем фактическом коде в файле commands.ts. Также в функции «createBooking» мне пришлось покрыть все текстовые / числовые поля вводом данных. Как упоминалось ранее, после ввода всех полей и вызова POST я убедился, что все запросы и ответы пары ключ-значение соответствуют требованиям.

Поскольку мне приходилось утверждать несколько ключей и значений и поддерживать их в чистоте в соответствии с одним ожиданием, утверждения BDD Chai 'to.include' лучше всего подходят для этих сценариев по сравнению с ( .to.have.property). Как видно из примера кода, если какая-либо из пар «ключ-значение» не совпадает, полный блок «it test» завершится ошибкой.

После изучения всех различных ролей команд входа в систему и многоразовой команды createBooking я сосредоточился на написании тестовых примеров для различного набора пользовательских ролей и установке утверждений в соответствии с ними.

Здесь, в файле спецификации теста (который находится в папке интеграции), я перенаправил все свои вызовы API на функцию beforeEach. Cy.route работает как слушатель для xhr requests.

В этом примере я показал, как я вложил три тестовых случая (его блок) внутрь описания («пользовательские случаи TL»). Я сделал отдельный describe () для каждого вошедшего в систему пользователей с ролью, которые не показаны на этом снимке экрана. Причина написания этого отдельно заключается в том, что я хотел написать cy.login () внутри определенного describe () beforeEach, чтобы охватить все случаи этого пользователя, а также хотел чтобы мой код был читабельным.

1] Первый тестовый пример был простым, но он сэкономил достаточно времени для повторного тестирования на этапе разработки.

Мне пришлось проверить, что значок «createBooking» должен быть виден только четырем ролям пользователей. Я написал тесты для вошедшего в систему пользователя и соответственно изменил should (‘be.visible’) / (‘not.be.visible’).

2] Поскольку этот пользователь должен иметь доступ для создания бронирования, я вызвал функцию, написанную в файле command.ts «createBooking ()». Мне также нужно было отправить случайное десятизначное число в качестве параметра для этого вызова функции, поэтому я использовал метод math.random () для генерации случайного числа, а также преобразовал его в строку (как показано во фрагменте кода выше). После вызова функции createBooking, как показано выше, я записал в нее все утверждения, поэтому тест даст соответствующий результат.

3] В этом тестовом примере мне нужно было проверить, возвращает ли конечная точка попадания / бронирования статус 403 для этого пользователя. Если бы я не передал failOnStatusCode: false в строке номер 4, тест не прошел бы, поскольку код состояния не был 2xx или 3xx, и я не смогу передать неверные коды состояния, что является преднамеренным . Таким образом, передача failOnStatusCode: false в cy.request () решает мою проблему в этом варианте использования, который я выполняю в 10 разных тестовых случаях.

До использования Cypress я писал тесты интерфейса и API отдельно с разными инструментами. Но с Cypress я мог автоматизировать интерфейс, а также ждать завершения вызовов API и подтверждать его «запрос-ответ» и соответственно ожидать сообщений об успешном / неудачном завершении пользовательского интерфейса. Также с помощью Cypress я мог решить, следует ли заглушить ответы или позволить им попасть на ваш сервер, отложить ответ и т. Д.

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

Также планируется выпуск фазы 2 и 3 для этой функции, я собираюсь перенести эти знания и опыт на оставшуюся часть предстоящих тестов.

Спасибо