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 |
но это не очень динамичный.... надеясь на лучшее решение? :)
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 |
Я не думаю, что то, что вы просите, возможно с помощью SpecFlow, огурца и огурца из коробки. Я не могу говорить за авторов, но я уверен, что он намеренно не предназначен для использования таким образом, потому что он идет против общего "потока" написания и реализации этих спецификаций. Среди многих вещей, спецификации предназначены для чтения для не-программистов, чтобы дать программисту руководство по реализации кода, который соответствует спецификациям, для интеграционного тестирования и дать certian количество гибкость при рефакторинге.
Я думаю, что это одна из ситуаций, когда боль, которую вы чувствуете, является признаком того, что есть проблема, но это может быть не тот, о котором вы думаете. Ты сказал:
" однако сценарии копирования / вставки для разных тестов фильтров станут повторяющимися и займут много кода - чего я хотел бы избежать. "
первый, Я бы не согласился с тем, что объяснение себя в письменной форме является "повторяющимся", по крайней мере, не больше, чем это повторяющиеся, чтобы использовать конкретные слова, такие как " the, apple, car и т. д."снова и снова. Вопрос в том, правильно ли эти слова объясняют то, что вы делаете? Если это так, и объяснение вашей ситуации требует от вас написать несколько сценариев, то это именно то, что требуется. Общение требует слов, а иногда и одних и тех же.
фактически, то, что вы называете "повторяющимся", является одним из преимуществ использования огурца и такого инструмента, как огурец или SpecFlow. Если вы можете использовать это предложение снова и снова, снова и снова, это означает, что вам не нужно писать тестовый код снова и снова, снова и снова.
второй, вы уверены, что пишете спецификацию для правильной вещи? Я спрашиваю только потому, что если количество сценариев выходит из-под контроля, до такой степени, что человек не может следить за тем, что вы пишете, возможно, что ваша спецификация не нацелена на правильную вещь.
возможным примером этого может быть то, как вы тестирование фильтрации и разбиение на страницы в этом сценарии. Да, вы хотите, чтобы ваши спецификации охватывали все функции, и ваш сайт будет иметь разбиение на страницы на той же странице, что и ваша фильтрация, но какой ценой? Требуется опыт и практика, чтобы знать, когда отказ от предполагаемого "идеала" без насмешек, тесты полной интеграции дадут лучшие результаты.
третий, не думайте, что спецификации предназначены для идеального покрытия для каждого возможного сценария. Этот сценарии-это в основном моментальные снимки состояния, что означает, что есть некоторые функции, которые могут охватывать бесконечно большой набор сценариев, что невозможно. Так что ты делаешь? Напишите функции, которые расскажут историю как можно лучше. Пусть даже история будет движущей силой развития. Однако детали, которые не переводятся в ваши спецификации или другие случаи, лучше оставить прямому TDD, сделанному в дополнение к спецификациям.
в вашем примере кажется, что вы в основном рассказываете историю о сайт, который позволяет пользователю создавать динамический поиск сладостей и конфет. Они вводят один из большого набора возможных критериев поиска, нажимают кнопку и получают результаты. Просто придерживайтесь этого, написав достаточно спецификаций, чтобы выполнить историю. Если вы не удовлетворены своим покрытием, очистите его с помощью дополнительных спецификаций или модульных тестов.
в любом случае, это только мои мысли, надеюсь, это поможет.