Ограниченные по объему функцией определения шага с SpecFlow?
Я использую SpecFlow, чтобы сделать некоторое тестирование стиля BDD. Некоторыми моими функциями являются тесты UI, таким образом, они используют WatiN. Некоторые не тесты UI, таким образом, они не делают.
В данный момент у меня есть сингл StepDefinitions.cs файл, покрывая все мои функции. У меня есть a BeforeScenario шаг, который инициализирует WatiN. Это означает, что все мои тесты запускают Internet Explorer, нужен ли им он или нет.
Есть ли какой-либо путь в SpecFlow, чтобы иметь конкретный файл функции, связанный с определенным набором определений шага? Или я приближаюсь к этому от неправильного угла?
3 ответа
Есть простое решение вашей проблемы, если вы используете теги.
Первый тег, который вы добавляете в файл, чтобы указать, что конкретная функция нуждается в WatiN, например:
Функция: требуется сохранить пропорцию пула выборки Как <Пользователь> Я хочу <Настроить размер требуемого образца> так что <я могу посоветовать группе развертывания требований к ресурсам>. @WatiN Сценарий: сохранить допустимый размер выборки в среднем диапазоне Учитывая, что пользователь вводит 10 в качестве размера выборки Когда пользователь выбирает сохранить Затем значение сохраняется
Затем украсьте привязку BeforeScenario атрибутом, указывающим тег:
[BeforeScenario("WatiN")]
public void BeforeScenario()
{
...
}
Этот метод BeforeScenario будет вызываться только для функций, использующих WatiN.
В настоящее время (в SpecFlow 1.3) определения шагов являются глобальными и не могут быть ограничены конкретными функциями.
Это сделано специально, чтобы иметь такое же поведение, как у Cucumber.
Я задал тот же вопрос о группе огурцов:
Исходным является то, что язык определен по всем файлам функций также должны быть глобальными (одно глобальное поведение всего приложения). Поэтому следует избегать определения объема функций. Лично я еще не полностью убежден в этом ...
Однако ваша проблема с запуском WatiN только для сценариев, требующих интеграции пользовательского интерфейса, может быть решена двумя разными способами:
Теги и привязки с тегами: вы можете пометить свои сценарии (т.е. с @web) и определите в BeforeScenario-Hook, который должен запускаться только для сценариев с определенным тегом (например, [BeforeScenario ("web")]). См. Интеграцию Selenium в нашем примере BookShop: http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs
Мы часто полностью разделяем сценарии, привязанные к пользовательскому интерфейсу, и сценарии, привязанные к программному API (например, контроллер, модель представления ...), в разные проекты. Мы попытались проиллюстрировать это в нашем примере книжного магазина: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/ .
Первоначально я предполагал, что файл шага был связан с конкретным файлом функции. Как только я понял, что это неправда, это помогло мне улучшить весь мой код SpecFlow и файлы функций. Язык моих файлов функций теперь меньше зависит от контекста, что привело к большему количеству многоразовых определений шагов и меньшему дублированию кода. Теперь я упорядочиваю свои файлы шагов в соответствии с общими чертами, а не в зависимости от того, для какой функции они предназначены. Насколько мне известно, невозможно связать шаг с определенной функцией, но я не эксперт по SpecFlow, поэтому не верьте мне на слово.
Если вы все же хотите связать свои файлы шагов с определенным файлом функций, просто дайте им похожие имена. Нет необходимости заставлять его работать только для этой функции, даже если код шага имеет смысл только для этой функции. Это связано с тем, что даже если вам случится создать повторяющийся шаг для другой функции, он обнаружит это как неоднозначное совпадение. Поведение при неоднозначных совпадениях можно указать в файле App.config. Видеть http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf подробнее о файле App.config. По умолчанию неоднозначные совпадения обнаруживаются и сообщаются как ошибка.
[править]: На самом деле, есть проблема с работой таким способом (только в голове у вас есть файлы шагов, связанные с файлами функций). Проблема возникает, когда вы добавляете или изменяете файл.feature file и используйте ту же формулировку, которую использовали ранее, и вы забываете добавить для него шаг, но вы этого не замечаете, потому что вы уже создали шаг для этой формулировки один раз раньше, и он был написан в контекстно-зависимой манере . Кроме того, я больше не убежден в полезности того, чтобы не связывать файлы шагов с файлами функций. Я не думаю, что большинство клиентов могли бы хорошо написать спецификацию независимо от контекста. Мы обычно не так пишем, говорим или думаем.