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 |

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

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 |

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

2 17
cucumber specflow gherkin automated-tests

2 ответа:

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

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

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

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

Быть пользовательским шагом, как 

I should have output that contains <output>

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

Then "I should see #{iterated_value}"

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

| 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 |
Как бы то ни было, вам, возможно, следует принять слова Даррена близко к сердцу. Я не совсем уверен, что этот метод поможет конечной цели иметь сценарии, которые читаются не разработчиками.
7

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

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

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

Во-первых, я бы не согласился с тем, что объяснять себя в письменной форме-это "повторение", по крайней мере, не больше, чем повторять определенные слова, такие как "the, apple, car и т. д.- снова и снова. Вопрос в том, правильно ли эти слова объясняют то, что вы делаете? Если они есть, и объяснение вашей ситуации требует, чтобы вы написали несколько сценариев, то это именно то, что требуется. Общение требует слов, а иногда и тех же самых.

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

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

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

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

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

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

34