Определения эталонных областей с SpecFlow?

Question

Я использую SpecFlow для тестирования BDD-стиля. Некоторые из моих функций - тесты UI, поэтому они используют WatiN. Некоторые из них не являются тестами UI, поэтому они этого не делают.

На данный момент у меня есть файл StepDefinitions.cs, охватывающий все мои функции. У меня есть шаг BeforeScenario, который инициализирует WatiN. Это означает, что все мои тесты запускают Internet Explorer, независимо от того, нужны они или нет.

Есть ли какой-либо способ в SpecFlow иметь конкретный файл функций, связанный с определенным набором определений шагов? Или я подхожу к этому с неправильного угла?

Answer 1

Существует простой способ решить проблему, если вы используете теги.

Первый тег вы особенность файла, чтобы указать, что конкретная функция должна WatiN так:

Feature: Save Proportion Of Sample Pool Required 
    As an <User> 
    I want to <Configure size of the Sample required> 
    so that <I can advise the deployment team of resourcing requirments>. 

    @WatiN 
    Scenario: Save valid sample size mid range 
    Given the user enters 10 as sample size 
    When the user selects save 
    Then the value is stored 

А затем украсить BeforeScenario связывания с атрибутом, который указывает тег:

[BeforeScenario("WatiN")] 
public void BeforeScenario() 
{ 
    ... 
} 

Этот метод BeforeScenario будет вызываться только для функций, которые используют WatiN.

Answer 2

Первоначально предполагалось, что файл шагов связан с конкретным файлом функции. Как только я понял, что это неправда, это помогло мне улучшить все мои кодеки и файлы функций SpecFlow. Язык моих файлов функций теперь меньше зависит от контекста, что привело к более многоразовым определениям шагов и уменьшению дублирования кода. Теперь я организую свои файлы шагов в соответствии с общими сходствами, а не по какой функции они предназначены. Насколько я знаю, нет способа связать шаг с определенной функцией, но я не эксперт SpecFlow, поэтому не задумывайтесь об этом.

Если вы все еще хотите связать свои файлы шагов с определенным файлом функции, просто укажите им похожие имена. Нет необходимости, чтобы он был вынужден работать только для этой функции, даже если код шага имеет смысл только для этой функции. Это связано с тем, что даже если вам удастся создать повторяющийся шаг для другой функции, он обнаружит это как двусмысленное совпадение. Поведение для двусмысленных совпадений может быть указано в файле App.config. См. http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf для получения более подробной информации о файле App.config. По умолчанию неоднозначные совпадения обнаруживаются и сообщаются как ошибка.

[edit]: На самом деле существует проблема с этим способом (с файлами шагов, связанными с файлами функций только в вашем уме). Проблема возникает, когда вы добавляете или изменяете файл .feature и используете ту же формулировку, которую вы использовали раньше, и вы забыли добавить для нее шаг, но вы этого не заметите, потому что вы уже создали шаг для этой формулировки один раз до , и это было написано в контексте чувствительным образом. Также я больше не убежден в полезности не связывания файлов шагов с файлами функций. Я не думаю, что большинство клиентов были бы очень хороши в написании спецификации в контексте независимо. Это не то, как мы обычно пишем, говорим или думаем.

Answer 3

В настоящее время (в SpecFlow 1.3) этапы определения являются глобальными и не могут быть привязаны к определенным функциям.

Это по дизайну имеет такое же поведение, как и огурец.

я задал тот же вопрос о группе огурца:

http://groups.google.com/group/cukes/browse_thread/thread/20cd7e1db0a4bdaf/fd668f7346984df9#fd668f7346984df9

Базовый том, что язык определяется всеми художественные файлами также должен быть глобальным (один глобальное поведением всего приложения). Поэтому следует избегать определения определений функций. Лично я еще не полностью убеждены в этом ...

Однако ваша проблема с началом WatiN только для сценариев, которые нуждаются в UI-интеграция может быть решена двумя способами:

• Теги и помечено крючки: Вы можете пометить свои сценарии (то есть с помощью @web) и определить ina 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 (т.е. контроллер, вид-модель ...) в различные проекты. Мы попытались проиллюстрировать это в нашем примере BookShop: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/.

Answer 4

проверить это (новая функция в SpecFlow 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings

Answer 5

рассмотреть также с помощью реализации агностик DSL наряду с определениями шаг реализации. Например, используйте

When I search for 'Barbados'

вместо

`Когда я типа 'Барбадос' в поле поиска и нажмите кнопку Поиск

Реализуя мультипликатор то же, сценарий может выполняться через разные интерфейсы. Мы используем этот подход для тестирования пользовательских интерфейсов, API и т. Д., Используя тот же сценарий.

Answer 6

Решение для этого предназначено для реализации тегов & Скопированная привязка с тестовым сценарием, который связан с Интернетом или связан с логикой контроллера/ядра в коде.

И детализировать область для каждого сценария к любому из нижеуказанных До/После выполнения

BeforeTestRunScenario 
    BeforeFeature 
     BeforeScenario 
      BeforeScenarioBlock 
       BeforeStep 
       AfterStep 
      AfterScenarioBlock 
     AfterScenario 
    AfterFeature 
AfterTestRunScenario