Работа с несколькими небольшими вариациями в SpecFlow

Привет всем Мы разрабатываем веб-сервис, который будет доступен через SOAP и REST (xml и JSon). Наши функции specflow в основном одинаковы, т.е.:

Scenario: There are at least 3 radio Channels 
Given The test server is up and running 
And The previously obtained channel list is reset
When I request a list of radio channels
Then the resulting deliveryPackage contains a list of  at least 3 items

Все эти функции необходимо протестировать для интерфейса SOAP, для интерфейса REST/Xml и для интерфейса REST/JSon.

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

Я бы предпочел не писать каждый сценарий по 3 раза, чтобы изменить используемую реализацию шага.

Итак, два вопроса: 1) Как мне запустить функцию 3 раза для 3 разных интерфейсов, которые ожидают одни и те же сценарии? 2) Как каждый раз выбирать правильный файл шага?

Решение (1), вероятно, решит (2).


.net specflow cucumber bdd gherkin
person Pedro G. Dias    schedule 20.05.2011    source источник

Ответы (4)


arrow_upward
11
arrow_downward

Мой коллега дал нам хорошо работающее решение: Схема сценария:

Scenario Outline: Channels on different protocols
Given The test server is up and running
And The previously obtained channel list is reset
When I request a list of radio channels for the <protocol> and <binding>
Then the resulting deliveryPackage contains a list of  at least 3 items
Scenarios: 
| protocol | binding                          |
| XML      | BasicHttpBinding_IProgramService |
| JSON     | BasicHttpBinding_IProgramService |
| SOAP     | CustomBinding_IProgramService    |

За кулисами тестовый пример представляет собой функцию, которая получает два параметра, один для и один для .

Запуск этого сценария приводит к 3 модульным тестам, что мне и было нужно.

Подробнее здесь: Управление группами связанных сценариев

person Pedro G. Dias    schedule 30.05.2011

arrow_upward
1
arrow_downward

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

Но я не уверен, что это оправданное использование схемы сценария, которая в основном предназначена для изменения входных данных, а не для настройки инфраструктуры.

Другой вопрос, если SpecFlow является подходящим местом для настройки таких шагов, не должны ли эти детали быть проверены на другом уровне (тесты интеграции инфраструктуры и модульные тесты для компонентов), поэтому Gherkin используется только для сквозного приемочного теста варианта использования. . Некоторое время назад я настаивал на том, что SpecFlow — неподходящий инструмент для таких тестов, но я вижу, что Gherkin успешно используется на всех уровнях, так что, возможно, ваш вопрос поднимает хороший вопрос о том, как SpecFlow (и Gherkin) можно использовать для реализации такого рода тестов. тестирования без повторения кода.

person Vagif Abilov    schedule 21.05.2011

arrow_upward
0
arrow_downward

В SpecFlow используется концепция, называемая тегированием. Вы можете украсить ступеньку биркой.

К сожалению, вам все равно понадобится сценарий, представленный трижды, но с разными @тегами.

Затем вы устанавливаете StepScopeAttribute в методе или классе, чтобы сказать, что этот метод/класс ограничен определенной функцией/сценарием/тегом. Вот пример проекта от автора:

https://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ScopedSteps

person Adam Houldsworth    schedule 20.05.2011
comment
Боюсь, это не идеальное решение, в итоге мы получим несколько тысяч функций, каждая из которых будет 3-кратной репликой - нет ничего, что соответствовало бы опции Cucumber, чтобы указать, откуда загружать файлы шагов? - person Pedro G. Dias; 20.05.2011
comment
Не то чтобы я в курсе. Вы всегда можете расширить исходный код, чтобы сценарий генерировал тест с атрибутом NUnit TestCaseAttribute. Затем это может предоставить тег, который затем разрешит правильный метод с помощью StepScope. - person Adam Houldsworth; 20.05.2011

arrow_upward
0
arrow_downward

Как насчет того, чтобы сказать:

When I request a list of radio channels for JSON, XML and SOAP
Then the corresponding resulting deliveryPackages contains a list of  at least 3 items

Каждое определение шага может включать три отдельных интерфейса.

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

person Andy Waite    schedule 21.05.2011