Cucumber-js: Хуки и хаки до/после

Созданный на 23 авг. 2017  ·  10Комментарии  ·  Источник: cucumber/cucumber-js

Я понимаю причину отсутствия хуков функций BeforeFeature/AfterFeature. Тесты в идеале должны быть изолированы. Однако из практических соображений производительности может быть предпочтительнее настраивать такие вещи, как фикстуры базы данных, один раз для каждой функции.

Обходной путь, указанный в #614, не подходит, потому что:

  1. Он не будет вызывать After, когда последовательные функции имеют один и тот же тег.
  2. Он не будет вызывать After, если помеченная функция была последним тестом в сборке.

До версии 3.0.0 эту функцию можно было взломать, используя контекст, переданный в качестве первого аргумента registerHandler('BeforeFeatures').

Есть мысли о том, чтобы принять PR для этой функциональности или предоставить аналогичный контекст в 3.0, чтобы, по крайней мере, снова сделать взлом возможным?

Самый полезный комментарий

+1 за хуки BeforeFeature/AfterFeature
Я согласен с необходимостью сбалансировать производительность с изоляцией тестов. В том виде, в котором сейчас построена структура, очень мало того, что связывает сценарии в одну функцию, за исключением повторяющихся фоновых шагов. В некоторых случаях мы можем не захотеть, чтобы фоновые шаги повторялись, а чтобы они выполнялись один раз в начале функции и прерывались только после завершения всех сценариев.

Все 10 Комментарий

Он не будет вызывать After, когда последовательные функции имеют один и тот же тег.

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

Он не будет вызывать After, если помеченная функция была последним тестом в сборке.

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


Также вы пытаетесь связать сценарии, что не рекомендуется. Я бы предложил одно из следующего:

  • отключить сценарии
  • несколько раз запускать огурец-js, загружая разные файлы поддержки, и использовать BeforeAll/AfterAll

Чтобы было ясно, обходной путь, о котором я говорю, таков:

this.Before({ tags: ['<strong i="6">@featurehook</strong>'] }, function () {
  // log user in (if needed)
})

this.Before({ tags: ['~<strong i="7">@featurehook</strong>'] }, function () {
  // log user out (if needed)
})

Рассмотрим некоторые особенности:

<strong i="11">@featurehook</strong>
Feature: feature 1
   Scenario: scenario 1

<strong i="12">@featurehook</strong>
Feature: feature 2
   Scenario: scenario 2

Feature: feature 3
   Scenario: scenario 3

<strong i="13">@featurehook</strong>
Feature: feature 4
   Scenario: scenario 4

Если они выполняются в порядке, указанном выше, разрыв не произойдет между функцией 1 и функцией 2. Удаление не произойдет и после функции 4, потому что не будет другого совпадения тестов ~ @featurehook (по общему признанию, это можно исправить с помощью После всего).

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

Возьмем пример теста, который настраивает тестовый SMTP-сервер с различными конфигурациями:

<strong i="20">@smtpConfig1</strong>
Feature: ....

<strong i="21">@smtpConfig2</strong>
Feature: ....

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

Извините, но я думаю, что это не то, что следует поддерживать. Существует возможность совместного использования состояния во всех сценариях и в одном сценарии, который охватывает подавляющее большинство случаев. Ваш пример в последнем комментарии (с @featurehook) в любом случае не решается наличием BeforeFeature / AfterFeature.

+1 за хуки BeforeFeature/AfterFeature
Я согласен с необходимостью сбалансировать производительность с изоляцией тестов. В том виде, в котором сейчас построена структура, очень мало того, что связывает сценарии в одну функцию, за исключением повторяющихся фоновых шагов. В некоторых случаях мы можем не захотеть, чтобы фоновые шаги повторялись, а чтобы они выполнялись один раз в начале функции и прерывались только после завершения всех сценариев.

Поскольку я использую такой сервис, как Browserstack, работа с которым постоянно медленная и болезненная (как и другие поставщики удаленных серверов, такие как Saucelabs), я обычно использую обработчики событий BeforeFeature и AfterFeature для настройки сеансов селена и разрыва для каждого файла функции.

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

Это следует рассматривать как случай, когда можно снова использовать хуки функций «До/После», а не выполнять Cucumberjs для каждого файла функций, как было предложено выше.

Хуки BeforeFeature/AfterFeature необходимы для e2e/uat/bdd/называйте-это-что-что-хотите-тестирования, для которого создан огурец.

Основные «конкуренты» Cucumber поддерживают это (например, JBehave, RobotFramework) и без каких-либо хаков; это правильная особенность фреймворка.

Эта проблема определенно блокирует использование Cucumber.

Привет... Я столкнулся с проблемой, связанной с этим. В моем случае я использую помеченные хуки «До» и «После» для создания/удаления данных, которые будут использоваться для тестирования пользовательского интерфейса. В хуке «До» я нажимаю конечную точку API и создаю данные, а в хуке «После» я нажимаю другую конечную точку API, чтобы удалить ее (я сохраняю идентификаторы объектов, возвращенные в ответе создания, а затем я создаю полезную нагрузку удаления с этими идентификаторами )

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

Любой способ обойти это??

Спасибо

+1 за функцию «До и после».
Наш вариант использования таков: мы находим ошибки в одних браузерах, которых нет в других.

Мы хотим пометить функцию следующим образом:

@ie-8-only
Business Need: IE8 should have limited functionality, but what is displayed, should be displayed correctly

@no-access @ssl-insecurity <strong i="8">@security</strong> @BUG-1876
Scenario: No access
   Given I am on the home page
   When I see that my browser is not supported
   Then I should not be able to access the core site functionality

@formatting-issue <strong i="9">@bugs</strong> @BUG-1210
Scenario: The menu should not be formatted like a staircase
   For the users to be able to navigate to the about us / contact us area of the site, the site navigation should be active
   Given I am on the home page
   When I see the menu
   Then it should be displayed in a line

Это позволит нам закрыть браузер и открыть IE в хуке BeforeFeature и снова открыть браузер, который мы используем для остальной части пакета, в хуке AfterFeature. Закрытие и повторное открытие браузера занимает много времени, когда вы делаете это для каждого сценария, что делает эту функцию полезной.

Примечание:
Я знаю, что есть альтернативы, которые включают объект мира (установка текущего браузера там и закрытие только в том случае, если браузер не тот, который нам нужен в хуке beforeAll для них), но кажется проще сделать это таким образом, и это должно быть уже сделано в хуке, или Selenium решит, что в половине случаев он будет шипеть.

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

Я думаю, что хуки функций до/после будут полезны для определенных типов тестов. Например, в Specflow, библиотеке Cucumber для .NET, реализовано следующее:
https://specflow.org/documentation/Hooks/

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

Была ли эта страница полезной?
0 / 5 - 0 рейтинги