Cucumber-js: В результате отсутствует сценарий и теги

Неа. Вы не можете легко получить доступ к тегам тестового примера. Плана по возвращению к результату старого сценария нет. В каком случае вам нужны теги?

В моем случае у меня есть зависимость от системы тегов. Чтобы получить данные в ахтерхук.

Что-то вроде этого:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

Вы можете создавать хуки, которые запускаются только для сценариев с определенными тегами: https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

У меня также есть несколько вариантов использования, чтобы узнать теги сценария. Учитывая следующий пример sudo (немного отсутствует синтаксис версии, поскольку у меня есть тестовые примеры в 1.3.1, и я смотрю на последнюю версию 3.0.1):

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

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

Могу я также спросить здесь, что я не могу получить объект результата в ловушке After в 3.0.1. Я пробовал testCase, сценарийResult и сценарий. Я что-то упускаю?

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

Затем в хуке after мы отправляем подробные результаты теста в нашу базу данных SQL. Эти результаты включают:

• идентификатор функции из TestRail - берется из тега (каждая функция имеет автоматически сгенерированный тег с идентификатором функции)
• сгенерированное исключение - взято из scenario.getException() в огурце 1.x
• все теги, которыми отмечен объект
• шаги, которые не удались - мы используем stepResult hook, чтобы получить результат каждого шага
• куча другой информации, взятой из TestRail с использованием идентификатора функции, взятого из тегов

Таким образом, с текущим изменением в cucumber 3.x мы никогда не сможем перейти на него, поскольку оно полностью разрушает нашу инфраструктуру.

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

Лично у меня есть скрипт-обертка, запускающий огурец.
Он загружает сценарии TestRail до запуска огурца, поэтому для меня не было большой проблемой переместить код отчета TestRail из крючков огурца в сценарий оболочки.
После завершения работы с огурцом сценарий считывает полученный JSON-файл cucumberResults и компилирует оттуда всю необходимую информацию.

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

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

@yaronassa, мы запускаем наши тесты через Protractor, мы не запускаем огурец напрямую, поэтому здесь есть еще один уровень абстракции.

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

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

Кроме того, создание настраиваемого средства форматирования только для получения результатов по шагам просто не звучит правильно.

Эй, я с тобой.
Я бы хотел неограниченный доступ к текущему состоянию огурца - функции, сценарию и шагу, со всей его коллекцией свойств и доступом на запись (я бы даже хотел получить доступ к будущему «стеку вызовов» сценариев с возможностью манипулировать им заранее ).

Видя, как cucumberJS сознательно отходит от такой «внутренней видимости», я предлагаю решения, которые, как мне кажется, могут сработать в обозримом будущем. Лично я думаю, что наступит время, когда мастерам вроде нас придется прибегать к переопределению внутренних методов в Cucumber internal, чтобы сохранить такой доступ.
И это нормально - я думаю, нас десяток и еще тысячи случайных пользователей.

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

@ gd46 вы можете сделать следующее:

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

Это не имеет никакого дублирования, кроме флага @set_video .

@pawelus

Затем в хуке after мы отправляем подробные результаты теста в нашу базу данных SQL.

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

@bnadim

Вы можете добавить снимки экрана с помощью функции attach чтобы они выводились в средствах форматирования событий potocol / json, а затем выполнить некоторую пост-обработку, чтобы сохранить их в файлы на основе имени сценария. Сторона нет: не гарантируется, что имя сценария будет уникальным, в отличие от URI сценария и номера строки.

@charlierudolph Я полагаю, что это

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

Один из таких примеров:

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

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

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

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

Я использую Cucumber-js для управления Selenium. И локальный, и Browserstack

Я использовал тестовое состояние (функция, сценарий, теги, результаты и т. Д.) В хуках для многих важных вещей.

• иметь специфичные для сценария изменения URL
• динамически пропускать тесты на основе текущей конфигурации браузера
• Используйте URL-адрес для конкретного сценария, чтобы записать результаты теста обратно в стек браузера.
• Используйте имена функций и сценариев для создания имен сеансов в Browserstack
• Теги синтаксического анализа для определения и установки разрешения браузера для конкретного сценария

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

Почему они были сброшены?
Они никогда не вернутся?

@ gd46

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

@justusromijn

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

@Jordyderuijter

Вы можете зарегистрировать строку сценария и uri (который на самом деле уникален и избавляет вас от необходимости искать имя сценария).

@leggebroten

иметь специфичные для сценария изменения URL

Вместо этого вы можете использовать шаг или использовать уникальные теги

динамически пропускать тесты на основе текущей конфигурации браузера

Как вы динамически пропускали тесты? # 912 добавляет поддержку для этого

Используйте URL-адрес для конкретного сценария, чтобы записать результаты теста обратно в стек браузера.

Вместо имени можно использовать строку и uri. Как отмечалось ранее, строка и uri гарантированно уникальны, а имя - нет. Я также предлагаю разобрать модуль форматирования json или модуль форматирования протокола событий на предмет результатов тестирования и использовать вложения, если вам нужно что-то добавить.

Используйте имена функций и сценариев для создания имен сеансов в Browserstack

Вы можете использовать строку + URI

Теги синтаксического анализа для определения и установки разрешения браузера для конкретного сценария

Вы можете использовать для этого ступеньку.

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

@charlierudolph спасибо за ответ. Что касается mockserver, у меня уже был быстрый чат с некоторыми коллегами, и использование общего «фона» рассматривалось как решение, так что да, вы можете вычеркнуть это из списка.

@charlierudolph Спасибо за ответ.

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

0) Несоответствие паттерну наблюдателя. Обратным вызовам должны быть предоставлены данные, необходимые для поведения, которое они поддерживают.

1) Вызывает крайнюю хрупкость. Тесты должны быть надежными, иначе им не будут доверять. Номера строк и имена файлов меняются. Простое добавление или удаление возврата каретки нарушит тесты.

2) Использование шагов для изменения состояния нарушает DRY. Рассмотрим частый случай добавления A / B-тестов, помеченных тегом. Если вы не добавите расширение командной строки для выполнения тестов на основе шагов, которые они включают, для тестов потребуются ОБА тега и поддерживающие их шаги, изменяющие состояние.

3) Требует от разработчика дополнительной работы. Анализ вывода для поиска состояния является ненужным, утомительным, подверженным ошибкам, привязывает тесты к выходным форматам (плохая связь) и нарушает DRY.

4) Несовместимо с огурцом. Добавление шагов (семантическая часть теста) для изменения состояния функции противоречит намерению Cucumber изолировать средство записи тестов. Если поведение не изменилось, тест не должен.

5) Это не декларативно. Теги - это метаданные О тесте, семантически непротиворечиво использовать их для изменения состояния, в котором будет выполняться тест. В то время как шаги встроены в тест. Вы идентифицируете набор тестов по их тегам… а не по шагам, которые они используют.

Да, и я на самом деле не «пропускал» тесты, я использовал обратный вызов (null, 'pending'), чтобы избежать запуска теста. Новая функция пропуска - лучшее решение.

@charlierudolph , я подумал, другое решение ...
при создании объекта World укажите ссылку на объект Scenario, используемый для теста.

Поскольку World доступен как "this" для всех обратных вызовов, он достигнет полного паритета с V2 (при условии, что обратному вызову AfterAll были предоставлены Результаты)

@leggebroten

1. Я никогда не слышал, чтобы шаблон наблюдателя был целью дизайна огурца.
2. Имена сценариев также хрупки, поскольку изменение одного символа также меняет их. Я согласен с разрывом номера файла / строки при выполнении действий, которые кажутся несвязанными. Я предлагал использовать их в отчетах о результатах, а не в проведении тестов, и поэтому хрупкая часть не имеет большого отрицательного эффекта.
3. Using Steps to alter State violates DRY Я этого не понимаю. Тег используется для выбора функций, а шаг используется для настройки / действий / ожиданий. Это разные цели. У нас есть минимальная поддержка использования тега для настройки с тегированными хуками, но он не предназначен для обработки сложностей.
4. Я предлагал только анализировать выходные данные форматирования для отчетов. Это не должно быть связано с запуском тестов.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer Я этого тоже не понимаю. Если вы не можете использовать шаги для выполнения действий и установки состояния, как вы выполняете тесты?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . Я не согласен с этим. Теги для меня предназначены только для идентификации тестов. Поддерживается минимальное изменение состояния, но не комплексное изменение состояния с параметрами.

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

@charlierudolph ,

Спасибо, что нашли время обсудить этот вопрос. Я искренне признателен за работу, которую вы проделали, чтобы предоставить нам Cucumber-js. Но в настоящее время я не могу перейти на V3.

Я не собираюсь быть агрессивным. Я просто волнуюсь, и это может проявиться в моих ответах.

Используя только документированный интерфейс событий из предыдущей версии, я создал структуру, которая значительно сокращает общее время выполнения теста, позволяя запускать функции одновременно в огромной настраиваемой матрице тестирования, включающей операционные системы / версии, браузеры / версии, рабочий стол / Мобильные и оптимизированные A / B-тесты.

Я НЕ МОГУ использовать шаги. Это очень поздно. Тип устройства, ОС / версия и браузер / версия ДОЛЖНЫ быть определены до начала теста, в противном случае каждый сценарий будет вынужден включать этап «настройка ОС» и этап «настройка браузера». Это прямо противоречит целям Cucumber.

В качестве альтернативы, как я упоминал ранее, вы можете предоставить информацию о сценарии (URI функции, имя, строка и теги) конструктору World. Это семантически согласуется с намерением объекта World и его проще инкапсулировать и расширить. Это не только устранит большинство моих обработчиков событий, но и, поскольку «this» обработчика является объектом World, это состояние соответствует шаблону наблюдателя.

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

2. Я не зависим от настоящих имен. Но поскольку они уникальны, они являются средством создания связанного значимого для пользователя имени сеанса в Browserstack.

3. Имея доступ к набору тегов во время работы Before, я мог создавать многократно используемые конструкции для изменения состояния (например, настройки параметров URL-адреса Optimizely) без изменения теста (добавления шагов). Это означало, что между тестами, которые я хотел запустить (Теги), и их настройкой была корреляция 1-1. СУХОЙ.

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

5. Очевидно, что шаги устанавливают тестовое состояние. Но одна из целей дизайна Cucumber заключалась в том, чтобы человек, пишущий шаги, был изолирован от основной реализации. EG тестирует семантическое поведение, не увязая в основных деталях. Добавление шагов для изменения параметров запроса и определение устройства / браузера / ОС кажется противоречащим этой цели.

6. Для вас Теги предназначены только для идентификации тестов. Но у Cucumber Wiki есть много применений для тегов.

7. Организация и группировка
8. Фильтры (запуск наборов через командную строку)
9. Ссылки на связанные документы (например, флаги Optimizely)
10. Указывает, где в процессе находится функция

Наличие доступа к тегам во время обратного вызова Before позволяет мне гарантировать соответствующее состояние на основе конфигурации браузера, которая используется для проведения теста. Использование тегов делает это декларативным. Использование шагов запутывает намерение

Вызовы и параметры обработчиков событий в предыдущих версиях БЫЛИ интерфейсом. Если разработчики связывают свой код с утечкой вашей реализации, передайте доступный только для чтения «Сценарий» прокси обработчикам событий.

@charlierudolph спасибо за ответ

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

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

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

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

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

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

FWIW, cucumber-ruby имеет две точки расширения, которые, я думаю, удовлетворяют принципу «легкие вещи должны быть легкими, сложные вещи должны быть возможны» и могут быть идеями, которые могут помочь в этих сценариях использования.

Прежде всего, мы передаем экземпляр RunningTestCase каждому хуку. Это неизменяемый объект значения, который содержит всю информацию об источнике Gherkin (сценарий / схема / теги и т. Д.), А также текущий статус результата сценария. Неизменяемость означает, что мы защищены от необходимости рассматривать случаи, когда пользователь может попытаться изменить что-то на нас, но в равной степени это дает им прозрачность в отношении текущего состояния игры.

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

HTH

Я только что понял, что документация по этой ссылке для фильтров ужасна! Извините. Сейчас нет времени исправлять, но здесь есть еще несколько примеров: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

Привет @charlierudolph!

Извините, прошло некоторое время с тех пор, как я продолжил этот разговор. Не могли бы вы подробнее рассказать о своем заявлении:

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

Я не уверен, что понимаю.

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

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

Пример результата от PickFilter:

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

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

Если вам интересен мой пример, я использую его здесь: https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph Здесь устанавливается testCase?

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

Из того, что я могу сказать, есть ссылка на pickle рядом с testCase. Так почему бы не вернуть еще несколько битов из результата рассола в результат testCase?

@ gd46 хорошо, давайте добавим pickle к объекту, который передается ловушке, заменяющей sourceLocation. Это необходимо обновить в этой функции: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

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

@charlierudolph Просто хотел прояснить изменение. Согласны ли мы с той разницей, что pickle содержит uri без номера строки непосредственно на нем, как это делает sourceLocation. И если кто-то хочет использовать uri с номером строки, он может использовать номера строк, возвращенные из объекта pickle? Я не вижу в этом никаких проблем, просто хотел подтвердить.

Я думаю, давайте оставим исходный объект местоположения как есть (вместо его удаления) и добавим объект рассола.

Хорошо, это работает и для меня. Итак, я новичок в создании огурца, я все еще пытаюсь понять структуру.

Поскольку вы указали строку, которую необходимо обновить, я считаю, что мы можем просто добавить что-то вроде этого рядом с sourceLocation:

pickle: this.testCase.pickle

Тогда любой, кто хочет использовать его в хуке, может получить к нему доступ следующим образом:

testCase.pickle.tags
testCase.pickle.name
etc. 

Я сделал обновление, но я не уверен на 100%, как обновить все связанные тесты. Не могли бы вы дать какие-нибудь рекомендации?

Я смог протестировать изменение, связав свою вилку с изменениями в одном из моих локальных проектов. Полный результат testCase будет выглядеть так:

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

Проведя еще несколько тестов, я заметил, что pickle не содержит uri в то время, когда у нас есть доступ к нему в test_case_runner. Так что я думаю, что можно оставить исходное местоположение таким, как оно есть.

PickleFilter возвращает рассол как:

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

Так что все будет так же, за исключением маринованного огурца, в котором нет ури.

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

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

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