Как увеличить возможность повторного использования между этапами SpecFlow/Gherkin?

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

Наши сценарии уже соответствуют различным рекомендациям

• . Не требует пояснений
• Должен иметь понятную цель (, что отличает его от других сценариев)
• уникальны
• Представлять вертикальные функциональные срезы
• Использует вездесущий язык
• Написано с точки зрения заинтересованных сторон
• О бизнес-функциональности, а не о дизайне программного обеспечения
• Сгруппировано по эпикам
• НЕ ЯВЛЯЮТСЯ ТЕСТИРОВАННЫМИ СКРИПТАМИ
• Пусть кто-нибудь прочтет их, чтобы убедиться в правильности сценария
• Не относится к элементам пользовательского интерфейса
• Представляют ключевые примеры
• Не технические -технические
• Точный и проверяемый
• Максимально воспроизводимый
• «Данное» представляет состояние, а не действия
• «Когда» представляют собой действия
• «Тогда» должно представлять видимое изменение, а не какое-то внутреннее событие

. Наши шаги должны соответствовать следующим рекомендациям (, некоторые из которых относятся к SpecFlow):

• Использует вездесущий язык
• Не относится к элементам пользовательского интерфейса
• Не следует сочетать
• Должен быть многоразовым и глобальным для всех функций
• Не следует связывать с определенной функцией
• Сгруппировано по сущностям, группам сущностей или понятиям предметной области
• Не создавайте шаги для повторного использования логики в файле определения шагов
• . Тщательно продумайте, к какому файлу Steps относится шаг
• Не используйте повторно шаги между фазами
• Следует избегать буквенных строк в шагах,но при необходимости используйте одинарные кавычки
• Никогда не применяйте к шагу несколько атрибутов [Дано], [Когда] или [Тогда]. метод
• Порядок шагов в соответствии с фазой, которую они представляют
• Если это не важно для сценария, очень важно не упоминать об этом

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

Рассмотрим, например, следующий сценарий:

Feature: Signing where both persons are physically available

@Smoke
Scenario: Show remaining time to sign based on previous signature
  Given a draft proposal
  And the first signature has been set
  When I try to set the second signature
  Then the remaining time to sign should be shown

@Smoke
Scenario: Re-signing of the first proposal
  Given a signature that has not been set within the configured time
  And the first signature has just been re-signed
  When I try to set the second signature
  Then the remaining time should start over

Было бы лучше объединить два «данных» шага в один и потерять возможность повторного использования?

Некоторые другие примеры:

Feature: Conditionally show signatures to be signed

@Smoke
Scenario: Show the correct signature for a proposal with a night shift
  Given I have a proposal for the day shift
  When I change it to the night shift
  Then I should only be able to sign for the night shift

@Smoke
Scenario: Show additional signature when extending the shift
  Given I have a suspended proposal for the night shift
  When I extend the period to the day shift
  Then I should confirm extening the period over the shift

Я пропустил фундаментальную концепцию здесь?