Cucumber-js: результат сценария не передается в хуки до / после

Меня это укусило. Наше обновление до 3 на cucumber pro приостановлено из-за этого.

Https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/runtime/test_case_runner.js#L109 виноват?

Какая именно часть этого нужна? Вы используете только предикаты статуса? Кажется, это единственное, что используется в документах, связанных с этим

В настоящее время мы используем scenarioResult.status , scenarioResult.scenario.uri и scenarioResult.scenario.line .

@jbpros Ваш вариант использования соответствует примерам, которые у нас есть в настоящее время (сохранение снимка экрана в случае сбоя сценария)? Я всегда думал, что это действительно странно, что сценарий был передан в хуки, и хотел бы найти другой способ справиться с этим.

В настоящее время я думаю, что мы добавим новую функцию кода поддержки: onFailedTestStep которая позволяет вам установить функцию, которая будет вызываться с ошибкой на этапе тестирования. Он будет вызываться с тем же аргументом мира, что и неудачный шаг, и, таким образом, вы можете прикрепить изображение или что-то в этом роде. Мы могли бы создать специальный модуль для разбора вложений из средства форматирования протокола событий и копирования их в папку.

Как пользователь-мастер, я хотел бы, чтобы любая такая функция / обработчик / объект имела как можно больше контекста. Даже без чего-то грандиозного, как все дерево прогонов прошлого и будущего (https://github.com/cucumber/cucumber-js/issues/875), было бы чрезвычайно полезно знать, каков текущий шаг и сценарий для каждая неудача.
Например, это позволяет мне контролировать процедуры отката в соответствии с тегами или просто видеть, какие еще шаги были выполнены до неудачного.

Я бы посоветовал вам рассмотреть возможность передачи их в onFailedTestStep , если вы выберете это решение.

Также необходимо обновить Hook Docs - ссылка в первом абзаце на ScenarioResult - это 404.

Почему бы не определить ловушку с именем AfterStep вместо onFailedTestStep AfterStep ? Огурец-Рубин имеет это уже давно, и, как вы знаете, важна последовательность.

@aslakhellesoy Я хочу сосредоточиться на

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

Можете ли вы, @mattwynne или кто-то из команды ruby ​​пролить свет на то, для чего был создан AfterStep и для чего он используется?

Я не из команды Ruby, поэтому не знаю, для чего был создан AfterStep , но я лично использую AfterStep для выполнения различных операций. Вот некоторые примеры:

1. Сделайте снимок экрана и выведите журнал браузера при неудачных сценариях
2. Вести дополнительный журнал для какого-либо проекта независимо от того, провалился он или нет
3. Очистить

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

Это означает, что если бы было что-то вроде onFailedTestStep , у нас было бы несколько способов добиться того же: один - использовать AfterStep а другой - использовать onFailedTestStep .

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

@charlierudolph

Я хочу понять, откуда вы. Не могли бы вы пояснить, почему вы так думаете?

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

Мне никогда не нравилось смешение двух парадигм. Хуки до / после связаны с установкой / разборкой с фактическим запуском тестов. Использование его также для отчетности кажется чем-то, о чем следует позаботиться отдельно.

Сделайте снимок экрана и выведите журнал браузера при неудачных сценариях

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

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

Какой тип дополнительного ведения журнала вы делаете?

Очистить

Что нужно убирать после ступеньки?

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

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

Это означает, что если бы было что-то вроде onFailedTestStep, у нас было бы несколько способов добиться того же: один - использовать AfterStep, а другой - использовать onFailedTestStep.

Cucumber-js в настоящее время не имеет AfterStep и я не планирую реализовывать оба варианта.

Я пытаюсь получить поддержку cucumber 3 в protractor-cucumber-framework, и я действительно мог бы использовать AfterStep . Я понимаю, что библиотека, объединяющая две другие библиотеки, - не самый распространенный вариант использования, но это значительно упростило бы ее. Я пытаюсь понять, как это сделать с помощью нового протокола событий, но у меня нет контекста функции / сценария / шага ни в одном из событий *-finished . Мы используем имена, uris и номера строк из функции, сценария и шагов, чтобы сообщить транспортиру и дать интеграции IDE (Intellij) что-то, что можно показать и перейти в их дереве. В любом случае мои 0,02 доллара.

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

Так, например, я использую его для реализации шага «Следующий шаг должен завершиться ошибкой с ошибкой XYZ», который позволяет мне быстро реализовывать глубокие отрицательные проверки и моделирование ошибок без реализации повторяющихся отрицательных шагов или специальной изменяемой обработки ошибок на каждом шаге. .

Я думаю, что хук AfterStep может сделать того, чего не может setDefinitionFunctionWrapper .

Есть обновления по этому поводу? Пытаюсь выполнить обновление с 2.0.0 до 3.0.0 на работе, но все еще не определено для сценария

@ paul-phillips-ark да, см. №905. Если вы хотите помочь продвинуться вперед, вы можете разветвиться и отправить новый PR, который обращается к комментариям

Когда я использую console.log (сценарийResult), я все еще получаю undefined как в функциях до, так и после? Я что-то упускаю? Приносим извинения, если комментарий выше звучит слишком плотно.

Мои варианты использования в настоящее время следующие:

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

Before({ timeout: 60 * 1000 }, scenarioResult => {
    ...
    const file = scenarioResult.scenario.feature.uri;
    ...
});

На крючок After как многие из нас делают скриншот:

After(scenarioResult => {
    if (scenarioResult.status === 'failed') {
      driverUtils.takeScreenShot(scenarioResult.scenario.name);
    }
});

@charlierudolph, не могли бы вы вырезать релиз с запросом на

Есть некоторые проблемы для # 905, но я постараюсь исправить и выпустить релиз на этих выходных.

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