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

Question

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

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).

Answer 1

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

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 модульных теста, что я и сделал.

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

SpecFlow имеет концепцию под названием тегирование. Вы можете украсить шаг с помощью тега.

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

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

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