Определения шагов с ограниченным набором функций с помощью SpecFlow?

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

Сначала отметьте файл функции, чтобы указать, что конкретная функция нуждается в 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.

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

Это сделано специально, чтобы иметь такое же поведение, как у Cucumber.

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

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

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

Однако ваша проблема с запуском 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 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings

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

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

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

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

И разверните область действия каждого сценария до любого из нижеперечисленных до / после выполнения.

BeforeTestRunScenario 
    BeforeFeature
        BeforeScenario
            BeforeScenarioBlock
                BeforeStep
                AfterStep
            AfterScenarioBlock
        AfterScenario
    AfterFeature
AfterTestRunScenario 

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

When I search for 'Barbados'

вместо

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

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