Один из вопросов, которые мне чаще всего задают на вебинарах, это: «Как мне использовать "X" в Cucumber?» Идет ли речь о тестировании API, cy.session() или другой функциональности, Cucumber, похоже, является обязательным требованием для многих команд. Основное преимущество Cucumber — возможность использовать синтаксис Gherkin для определения тестов. Все тесты пишутся как сценарии поведения, и поэтому тесты не только выполняют роль проверки функциональности, но также выступают в роли живой документации. Цель такого подхода — обеспечить большую видимость предмета тестирования. Преимущество заключается в том, что помимо инженеров, также и другие заинтересованные стороны могут проверить, выполняются ли критерии приемки. Я видел, как этот подход хорошо работает в медицинском и банковском секторе, где тесты были не только функциональными, но и использовались для создания документации или отчетов высокого уровня. В прошлом я был известен тем, что критиковал синтаксический подход Gherkin. Мое основное возражение против него заключается в том, что он использует подход «черного ящика» к тестированию. Я считаю этот подход не очень эффективным — особенно в Cypress. Тесты Cypress выполняются внутри браузера, что дает возможность проникнуть во внутреннее устройство приложения, получить доступ к API, кэшировать сессии, изменять состояние приложения, имитировать сеть. Хорошо разработанные тесты Cypress могут помочь достичь приличного покрытия при небольшом количестве тестов. Придерживаясь подхода «черного ящика», пользователь не применяет все возможности Cypress и использует его просто как инструмент автоматизации тестирования. Есть также вопрос сопровождения и читаемости. Команды Cypress читабельны по умолчанию, и, применяя некоторые хорошие практики, тесты можно сохранить простыми в сопровождении даже для приложений, которые регулярно меняют свое поведение. Cucumber использует определения на основе шагов, которые заключают каждую серию команд в отдельный файл. Хотя они также могут характеризоваться хорошей читабельностью, любое изменение, внесенное в приложение, может потребовать переопределения или добавления нескольких шагов. Это означает, что чем больше система, тем сложнее вводить новые изменения. Глеб Бахмутов доступно объясняет в ролике на YouTube, насколько непростым может быть введение изменений в тесты на основе Cucumber. Учитывая все это, мне захотелось создать это руководство, чтобы вы могли при необходимости эффективно настроить Cypress с Cucumber. Я все еще верю, что вы сможете добиться успеха даже с этой моделью абстракции, так что давайте погрузимся в нее. Для начала необходимо установить плагин cypress-cucumber-preprocessor. В настоящее время существует несколько различных версий, но я считаю, что эта — лучшая, к тому же, она активно поддерживается. Для установки выполните следующую команду: Помимо установки препроцессора, в документации плагина рекомендуется установить бандлер esbuild от Глеба Бахмутова, благодаря которому запуск пройдет намного быстрее. После установки этих пакетов необходимо настроить Cypress на использование плагинов. Окончательная конфигурация будет выглядеть примерно так: Здесь есть, что распаковывать, поэтому предлагаю продвигаться шаг за шагом. Конфигурационный файл написан на TypeScript. Файл Javascript может быть немного проще, но по сути содержит все те же части. Нужно импортировать различные пакеты и добавить их в функцию setupNodeEvents(). Атрибут specPattern говорит Cypress, что нам нужно найти файлы .feature в папке e2e. Это означает, что он будет игнорировать все другие форматы и использовать в качестве теста только файлы .feature. Функция addCucumberPreprocessorPlugin() переварит эти .feature файлы и преобразует их в Javascript. Поскольку Cypress работает в браузере, нужно убедиться, что все, что мы запускаем (будь то .ts файлы .jsx или другие форматы), в конечном итоге будет скомпилировано в простой Javascript. Именно этим и занимаются препроцессоры. Часть on("file:preprocessor") занимается объединением плагина esbuild с плагином cucumber, чтобы они хорошо работали вместе. Заключительный оператор return config гарантирует, что все, что мы настроили, будет действительно установлено в конфиг. Этот шаг часто забывают, поэтому если плагины ведут себя так, будто они вообще не установлены, проверьте наличие этого оператора возврата. Поскольку компиляция в Javascript является важной частью работы с файлами .feature, обычно первоначальная настройка является самым большим препятствием, которое необходимо преодолеть. Я нахожу настройку из документации самой простой в работе, но если вы работаете с каким-то другим сборщиком, например, Webpack или Browserify, примеры можно посмотреть здесь. Теперь, когда плагин установлен и настроен, давайте рассмотрим, как писать тесты. Давайте начнем с написания простого тестового сценария в синтаксисе Gherkin. Создайте новый файл cypress/e2e/board.feature и добавьте в него следующее содержимое: Теперь нам нужно создать определения шагов для каждого этапа сценария. Самый простой способ определить шаги — создать новый файл board.ts в папке cypress/e2e, который может выглядеть примерно так: Можно поместить файл определения board.ts в папку cypress/e2e, или выбрать другое имя и поместить его в cypress/e2e/board или в папку cypress/support/step_definitions, и препроцессор cucumber автоматически подхватит их. Для пользовательского пути нужно явно указать это в конфигурации. К конфигурации мы перейдем позже в этой статье. Для улучшения опыта написания тестов в VS Code я рекомендую установить расширение от Александра Кречика. Оно обеспечит вам правильное выделение в файлах .feature и легкий доступ к определениям шагов. Определения шагов могут принимать параметры, что позволяет создавать более гибкие и многократно используемые сценарии тестирования. Давайте перепишем предыдущий файл определения шага так, чтобы можно было передавать в тест собственное имя: Параметры автоматически передаются в соответствующие функции определения шага в качестве аргументов. Обратите внимание на {string} в определении шага. Оно фактически проверяет, передается ли правильный тип в шаг. Теперь давайте создадим сценарий в файле cypress/e2e/board.feature, который принимает в качестве параметра boardName. Это будет выглядеть примерно так: Еще одна важная концепция в Cucumber, которую нужно знать, — это таблицы данных. DataTable в синтаксисе Gherkin позволяет передавать таблицу данных на шаг, что облегчает работу с несколькими наборами данных в сценариях тестирования. Это особенно полезно для тестирования на основе данных, когда вам нужно протестировать один и тот же сценарий с разными наборами входных данных. Таблицы данных определяются в разделе Examples файла .feature. Продолжим работу с предыдущим файлом: Определив шаги Examples, вы запустите тест несколько раз, передавая разные данные на каждом шаге. Обратите внимание, как мы создаем переменные boardName и listName, обернув их в <> для передачи в качестве параметров в определениях шагов. Эти таблицы данных также можно использовать для передачи данных в один шаг, как показано в следующем примере: Однако шаг должен быть в состоянии переварить таблицу данных. Вот как это можно сделать: Функция table.raw()[0] вернет первую строку () таблицы в виде массива. Внутри определения шага мы перебираем этот массив для создания элементов в списке. Помимо ключевых слов Given, When, Then и And, есть еще несколько способов организации нескольких тестов в одном файле .feature. До сих пор наш тест создавал новый board и новый list. Давайте немного изменим тест и создадим один тест, который просто создаст еще один board и поместит его перед существующим тестом: Аналогично блокам describe(), context() и it() в Mocha, мы можем дополнительно организовать тесты и сгруппировать их в логические кластеры. Ключевое слово Feature действует как блок describe() и служит группой верхнего уровня. Внутри области Feature можно добавить блок Rule, который еще больше разделит сценарии на подгруппы. По мере тестирования различных сценариев можно добавить шаг Background, который будет действовать подобно хуку beforeEach() в Mocha и запускать последовательность шагов перед каждым сценарием. Мы можем абстрагировать шаги Given и When от текущего файла .feature и тем самым сделать тест немного чище. Вместе с ключевым словом Rule тест может выглядеть примерно так: Пока есть возможность добавить Background, мы все еще можем определить шаги Before и After, которые действуют как хуки beforeEach() и afterEach() в Mocha. Сбой в них не приведет к ошибкам в тестах, так как они фактически выполняются внутри тестов. Шаги Before и After являются частью файла определения шагов, что означает, что их не требуется добавлять в файл .feature. Теги — это мощная функция в синтаксисе Cucumber, которая позволяет категоризировать и фильтровать сценарии. Вы можете использовать теги для запуска определенных сценариев или исключения сценариев из процесса тестирования. Чтобы добавить теги к сценариям, просто добавьте к сценарию или функции символ @, за которым следует имя тега. Например, добавим тег @regression к сценарию успешного входа в систему в файле cypress/e2e/board.feature: Чтобы запустить тесты с определенным тегом, используйте следующую команду: В результате будут пропущены тесты, не содержащие тег @smoke Это также можно проверить в режиме open, используя ту же команду, но с open вместо run. В дополнение к запуску всех тестов с определенным тегом, вы можете передать ключевое слово not, чтобы запустить все теги, кроме указанного. Есть также способ запуска всех тестов, содержащих любой из тегов: Или тесты, содержащие и то, и другое: Чтобы ускорить выполнение теста, можно использовать опции filterSpecs и omitFiltered, которые работают аналогично тому, как работает плагин @cypress/grep. Чтобы включить эту функциональность, добавьте следующие опции в файл cypress.config.ts: Существует два способа изменения стандартной конфигурации препроцессора Cucumber. Можно создать конфигурационный файл .cypress-cucumber-preprocessorrc.json, который будет выглядеть следующим образом: Или установите все прямо в package.json, добавив эквивалент: Настройки из примеров являются настройками по умолчанию. Если вы не хотите ничего менять, нет необходимости добавлять это в проект. Плагин Cucumber для Cypress поставляется с различными вариантами настройки отчетов. Я покажу самый простой — HTML-отчет. Все, что нужно сделать, это настроить конфигурацию: После запуска теста вы получите отформатированный HTML-отчет, который выглядит следующим образом: Если нужен более детализированный вывод, который вы впоследствии захотите проанализировать и передать в свою собственную систему отчетности, я рекомендую проверить json-formatter непосредственно у авторов cucumber. Его нужно будет установить отдельно и настроить его запуск в конфигурационном файле. Как я уже говорил в начале, есть более эффективные способы использования Cypress. Делать все еnd-to-end тесты с помощью UI — это излишество, и, учитывая дизайн Cypress, вы можете раскрыть гораздо больше возможностей, используя его так, как он был задуман. Приглашаем всех желающих на открытый урок, посвященный основам Cypress. Мы изучим основы фреймворка Cypress и рассмотрим, как его использовать для автоматизации тестирования веб-приложений. Рассмотрим основные принципы написания тестов с помощью этого фреймворка, а также поработаем с основными инструментами Cypress для создания и отладки тестов. Напишем несколько UI-тестов. Записаться на открытый урок  Переводчик, редактор