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

В другой статье я объяснил, как установить Cucumber вместе с Cypress для создания пользовательских историй и реализации каждого шага. Хотя основное внимание уделяется установке Cucumber, я также показал, как установить Cypress (на самом деле это одна командная строка).

Первые шаги

После установки Cypress в вашем проекте появится новая папка с именем cypress.

Внутри вы найдете еще 4 папки. Они:

  • Fixtures: в основном файл данных для вашей работы. Обычно используется для имитации данных ответов, но также может использоваться как папка consts.
  • Интеграция: здесь написан ваш тест кода.
  • Плагины: Название уже говорит все, верно?
  • Поддержка: это правильное место для размещения команд, которые могут вам понадобиться при выполнении тестов. Он запускается перед каждым тестом. Это означает, что здесь вы также можете поместить код для запуска каждый раз при запуске теста. Бывший:

Вы также можете использовать хуки для запуска вещей перед тестовым блоком (describe) или перед каждым тестом внутри этого тестового блока (перед каждым it).

Но что такое «это» и «описывать»?

Некоторые черты кипариса (такие как should, expect, it и describe) такие же, как в Мокко и Чай. На самом деле они просто импортированы и используются Cypress. Таким образом, Cypress поддерживает большинство этих функций.

Перед созданием тестов нужно указать, о чем feature этот тест. В Cypress мы говорим, что функция определяется describe. В качестве примера предположим, что у нас есть следующая страница входа:

Вот что он производит:

Если мы хотим протестировать эту страницу, то мы должны описать тест как страницу входа.

it указывает, какое поведение функции мы тестируем. В приведенном выше примере мы проверяем, может ли наш веб-сайт обрабатывать правильный вход в систему. Кроме того, мы могли бы проверить его поведение с неправильным именем пользователя и/или неправильным паролем.

Кипарисовые команды

ниже вы увидите список наиболее распространенных команд, которые используются на cypress. Язык чем-то похож на Typescript, то есть <command>(<input>: <type>).

Визит

Прежде всего, чтобы протестировать страницу, вам нужно быть на этой странице, верно? Для этого вам понадобится cy.visit(url: string). Бывший:

Получить

После посещения веб-сайта необходимо получить элемент либо для проверки его значения, либо для имитации клика. Для этого вы используете cy.get(DOMElement: string) . Вы можете дать на вход класс, тип, вообще все, что можно получить с помощью Jquery. Бывший:

В примерах, которые я покажу, я использую React для их кодирования. Тем не менее, я использую свойства HTML для поиска элементов. Итак, обычно вы увидите что-то вроде cy.get('[data-test=someValue]') .

Если вы посмотрите на DOM, то увидите, что почти все ключевые элементы будут иметь свойство с именем data-test. Это тег, который я буду использовать, чтобы получить их с помощью Cypress. Это помогает поддерживать шаблон для тестирования.

После cy.get вы можете связать больше команд.

  • Щелчок: после cy.get() элемента, если вам нужно имитировать щелчок по нему, используйте цепочку команд .click(). Пример тот же, что и выше.
  • Затем: команда .then($element: DOMElement | value: number) chainable позволяет вам использовать полученный элемент или значение. Если вы используете .then сразу после получения, элемент будет элементом jquery. Если вы используете .then после .its(value: JQueryCall) (что может быть чем-то вроде .its('length') ), результатом вызова будет значение .then. В данном случае число.
  • Должен: Проверять, верно ли условие. Cypress поддерживает команды Chai. Таким образом, вы можете использовать любой из них для утверждения. Бывший:

Ожидать

Это можно использовать в качестве альтернативы использованию get() с цепным .should(). Cypress подтверждает существование элемента по умолчанию, используя cy.get(), и, согласно этому утверждению, .should() следует использовать только для проверки значений элементов, полученных с помощью cy.get(). Для поддержания шаблона предпочтительнее использовать cy.get() и .should() для утверждения вместо ожидания.

Маршрут

Маршрут используется для имитации запроса, это может быть запрос GET, POST, Graphql… Вам просто нужно передать тип запроса, URL-адрес, который вы запрашиваете, и ответ. Последним может быть либо приспособление, либо все, что вам может понадобиться.

В приведенном ниже примере я использую .route() для имитации GET для URL-адреса todos/list, ожидающего json.

Светильники

Я мог бы просто создать константу с ответом. Но тогда это будет смешано с тестами, что не очень хорошо. Итак, Cypress создаст для вас папку с именем fixtures. Эта папка используется для хранения всех фиктивных данных, которые могут вам понадобиться. Затем, при использовании route, вам просто нужно сказать Cypress «Эй, дайте мне указанный прибор для этого запроса, пожалуйста», и он автоматически найдет его в папке приборов.

Надлежащая практика

Избегайте, насколько это возможно, тегов HTML или классов стилей.

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

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

Вы также можете использовать текст в элементе, но только тогда, когда вы не можете отличить одно свойство от другого. Например, у вас может быть много опций, но с разным содержимым, а содержимое является динамическим, поэтому вы не можете указать конкретное значение свойства option data-test. Тогда используйте строку опции.

Тестируйте одну вещь за раз

Еще одна вещь, которую нужно помнить (и я, возможно, не следовал ей, когда начинал), — это всегда тестировать вещи по одной и утверждать, что они существуют, прежде чем использовать их. Не пытайтесь проверить вход, делая все на ходу.

Опыт

Тестирование отзывов

Дана следующая задача:

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

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

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

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

Это все люди!

Пока что это мой опыт и знания, полученные при использовании Cypress. Это были хорошие американские горки, всякий раз, когда я думал, что мне нужно что-то проверить, Cypress мог с этим справиться. Кроме того, по мере роста моего опыта я буду обновлять эту статью и создавать новые, так что следите за обновлениями и спасибо!

Будущие исследования

Кипарис + огурец.

Тестовые файлы cookie и локальное/сеансовое хранилище.

Удалите data-test из кода перед запуском в производство. Можно использовать это, чтобы сделать это, может быть?

использованная литература

Разговор о тестировании в Cypress его создателя.

https://www.cypress.io/