Я не думаю, что то, о чем вы просите, возможно с SpecFlow, Gherkin и готовым огурцом.Я не могу говорить за авторов, но держу пари, что это намеренно не предназначено для использования таким образом, потому что это идет вразрез с общим «потоком» написания и реализации этих спецификаций.Помимо всего прочего, спецификации предназначены для чтения непрограммистам, чтобы дать программисту руководство по реализации кода, соответствующего спецификациям, для интеграционного тестирования и дать определенную степень гибкости при рефакторинге.
Я думаю, что это одна из ситуаций, когда боль, которую вы чувствуете, является признаком того, что есть проблема, но, возможно, она не та, о которой вы думаете.Вы сказали:
"Однако сценарии копирования / вставки для различных тестов фильтров станут повторяющимися и потребуют много кода - чего я бы хотел избежать."
Первый Я бы не согласился с тем, что объяснение себя в письменной форме является «повторяющимся», по крайней мере, больше, чем повторяющееся использование определенных слов, таких как «яблоко, машина и т. Д.»снова и снова.Вопрос в следующем: правильно ли объясняют эти слова то, что вы делаете?Если они есть, и для объяснения вашей ситуации требуется, чтобы вы записали несколько сценариев, то это как раз то, что требуется.Коммуникация требует слов, а иногда и одних и тех же.
На самом деле то, что вы называете «повторяющимися», является одним из преимуществ использования Gherkin и таких инструментов, как Cucumber или SpecFlow.Если вы можете использовать это предложение снова и снова, снова и снова, это означает, что вам не нужно писать тестовый код снова и снова, снова и снова.
Второй , вы уверены, что пишете спецификацию для правильной вещи?Я спрашиваю только потому, что, если количество сценариев выходит из-под контроля, до такой степени, что у вас так много, что человек не может следовать тому, что вы пишете, возможно, что ваша спецификация не нацелена на нужную вещь.
Возможным примером этого может быть то, как вы тестируете фильтрацию и нумерацию страниц в этом сценарии.Да, вы хотите, чтобы ваши спецификации охватывали все функции, и ваш сайт будет иметь нумерацию страниц на той же странице, что и ваша фильтрация, но какой ценой?Требуется опыт и практика, чтобы знать, что если отказаться от предполагаемого «идеала» бездействия, то тесты с полной интеграцией дадут лучшие результаты.
Третий , не думайте, что спецификациипредназначены для идеального освещения для каждого возможного сценария.Сценарии в основном представляют собой снимки состояния, что означает, что есть некоторые функции, которые могут охватывать бесконечно большой набор сценариев, что невозможно.Ну так что ты делаешь?Напишите функции, которые рассказывают историю как можно лучше.Даже пусть история движет развитием.Однако детали, которые не соответствуют вашим спецификациям или другим случаям, лучше оставить на усмотрение TDD, выполненные в дополнение к спецификациям.
В вашем примере кажется, что вы в основном рассказываете историю осайт, который позволяет пользователю создавать динамический поиск по конфетам и конфетам.Они вводят один из большого набора возможных критериев поиска, нажимают кнопку и получают результаты.Просто придерживайтесь этого, написав только достаточное количество спецификаций, чтобы наполнить историю.Если вас не устраивает ваше покрытие, попробуйте его с помощью дополнительных спецификаций или юнит-тестов.
В любом случае, это только мои мысли, надеюсь, это поможет.