SpecFlow/Cucumber/Gherkin - Использование таблиц в схеме сценария

Надеюсь, я могу объяснить свою проблему достаточно ясно, чтобы другие поняли, здесь мы идем, представьте, что у меня есть два следующих гипотетических сценария:

Scenario: Filter sweets by king size and nut content
Given I am on the "Sweet/List" Page
When I filter sweets by 
    | Field               | Value  |
    | Filter.KingSize     | True   |
    | Filter.ContainsNuts | False  |
Then I should see :
    | Value            |
    | Yorkie King Size |
    | Mars King Size   |

Scenario: Filter sweets by make
Given I am on the "Sweet/List" Page
When I filter sweets by 
    | Field        | Value  |
    | Filter.Make  | Haribo |
Then I should see :
    | Value   |
    | Starmix |

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

Scenario Outline: Filter Sweets 
Given I am on the <page> Page
When I filter chocolates by 
    | Field    | Value   |
    | <filter> | <value> |
Then I should see :
    | Output   |
    | <output> |
Examples:
    | page       | filter      | value  | output  |
    | Sweet/List | Filter.Make | Haribo | Starmix |

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

Обходной путь может быть примерно таким:

Then I should see :
    | Output |
    | <x>    |
    | <y>    |
    | <z>    |
    Examples:
    | x | y | z |

Но это не очень динамично.... надеясь на лучшее решение?:)

Ответ 1

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

Вызов шагов из шаговых определений

Например, я думаю, вы могли бы переписать

Then I should see :
| Output   |
| <output> |

Чтобы сделать такой шаг, как

I should have output that contains <output>

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

Then "I should see #{iterated_value}"

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

| page       | filter                               | value       | output                           |
| Sweet/List | Filter.KingSize, Filter.ContainsNuts | True, False | Yorkie King Size, Mars King Size |

Или, может быть,

| page       |                              filter-value-pairs | output                           |
| Sweet/List | Filter.KingSize:True, Filter.ContainsNuts:False | Yorkie King Size, Mars King Size |

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

Ответ 2

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

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

"Однако сценарии копирования/вставки для разных тестов фильтров станут повторяющимися и потребуют много кода - чего бы я хотел избежать".

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

На самом деле то, что вы называете "повторяющимся", является одним из преимуществ использования Gherkin и инструмента, такого как Cucumber или SpecFlow. Если вы можете использовать это предложение много раз и снова и снова, это означает, что вам не нужно писать тестовый код много раз и снова и снова.

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

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

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

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

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