Я понимаю причину отсутствия хуков функций BeforeFeature/AfterFeature. Тесты в идеале должны быть изолированы. Однако из практических соображений производительности может быть предпочтительнее настраивать такие вещи, как фикстуры базы данных, один раз для каждой функции.
Обходной путь, указанный в #614, не подходит, потому что:
До версии 3.0.0 эту функцию можно было взломать, используя контекст, переданный в качестве первого аргумента registerHandler('BeforeFeatures').
Есть мысли о том, чтобы принять PR для этой функциональности или предоставить аналогичный контекст в 3.0, чтобы, по крайней мере, снова сделать взлом возможным?
Он не будет вызывать After, когда последовательные функции имеют один и тот же тег.
Я не понимаю. Не могли бы вы рассказать об этом подробнее? Вы можете создать хук After
, зависящий от наличия или отсутствия тега. Обратите внимание, что синтаксис тега изменился с тех пор, как было предложено это обходное решение.
Он не будет вызывать After, если помеченная функция была последним тестом в сборке.
Опять же, я не понимаю этого, пожалуйста, объясните больше. Вы должны иметь возможность использовать хук After, но вы теряете контекст того, является ли он последним. В идеале вам не нужно делать демонтаж здесь.
Также вы пытаетесь связать сценарии, что не рекомендуется. Я бы предложил одно из следующего:
Чтобы было ясно, обходной путь, о котором я говорю, таков:
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/
Эта ветка была автоматически заблокирована, так как после ее закрытия не было никаких действий в последнее время. Пожалуйста, откройте новую проблему для связанных ошибок.
Самый полезный комментарий
+1 за хуки BeforeFeature/AfterFeature
Я согласен с необходимостью сбалансировать производительность с изоляцией тестов. В том виде, в котором сейчас построена структура, очень мало того, что связывает сценарии в одну функцию, за исключением повторяющихся фоновых шагов. В некоторых случаях мы можем не захотеть, чтобы фоновые шаги повторялись, а чтобы они выполнялись один раз в начале функции и прерывались только после завершения всех сценариев.