#.net #cucumber #bdd #specflow #gherkin
#.net #cucumber #bdd #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.
В cucumber можно запускать функции с помощью -R, чтобы указать, где расположены файлы steps, однако в SpecFlow я еще не нашел способ обойти файлы steps, чтобы одна и та же функция выполняла разные шаги.
Я бы предпочел не писать каждый сценарий 3 раза, чтобы изменить, какую пошаговую реализацию использовать.
Итак, два вопроса: 1) Как мне запустить функцию 3 раза для 3 разных интерфейсов, которые ожидают одни и те же сценарии? 2) Как мне каждый раз выбирать правильный файл step?
Решение (1), вероятно, решит (2).
Ответ №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 модульным тестам, что мне и было нужно.
Дополнительная информация здесь: Управление группами связанных сценариев
Ответ №2:
Единственное, что приходит мне на ум, — это использование scenario outline, которое позволяет определять семейство сценариев, а затем выполнять его вариации, предоставляя различные параметры в таблице.
Но я не уверен, что это оправданное использование схемы сценария, которая в основном предназначена для изменения входных данных, а не для настройки инфраструктуры.
Другой вопрос: если SpecFlow — подходящее место для настройки таких шагов, не следует ли эти детали тестировать на другом уровне (тесты интеграции инфраструктуры и модульные тесты для компонентов), поэтому Gherkin используется только для сквозного тестирования приемочного варианта использования. Некоторое время назад я бы настаивал на том, что SpecFlow — неподходящий инструмент для таких тестов, но я вижу, что Gherkin успешно используется на всех уровнях, поэтому, возможно, ваш вопрос поднимает хороший вопрос о том, как SpecFlow (и Gherkin) могут быть приняты для обеспечения такого рода тестирования без повторения кода.
Ответ №3:
В SpecFlow реализована концепция, называемая тегированием. Вы можете украсить шаг тегом.
К сожалению, вам все равно потребуется, чтобы сценарий был показан три раза, но с разными тегами @ .
Затем вы устанавливаете StepScopeAttribute в методе или классе, чтобы указать, что этот метод / класс ограничен определенной функцией / сценарием / тегом. Здесь есть пример проекта от автора:
https://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ScopedSteps
Комментарии:
1. Боюсь, это не идеальное решение, в итоге мы получили бы несколько тысяч функций, каждая из которых является 3-кратной копией — нет ничего, что соответствовало бы опции Cucumber указывать, откуда загружать файлы step?
2. Насколько я знаю, нет. Вы всегда можете расширить исходный код таким образом, чтобы сценарий генерировал тест с помощью атрибута NUnit TestCaseAttribute. Затем это могло бы предоставить тег, который затем разрешил бы правильный метод с использованием StepScope.
Ответ №4:
Как насчет того, чтобы сказать:
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
Определение каждого шага может включать в себя три отдельных интерфейса.
Однако я бы усомнился, является ли ваш подход разумным. Предполагая, что отдельные интерфейсы используют одну и ту же бизнес-логику, действительно ли вероятно, что сбой произойдет только в одном из трех? Возможно, было бы лучше протестировать небольшое количество ключевых методов во всех интерфейсах, а для большинства методов просто выбрать один интерфейс для тестирования?