Определение шагов в функциональной области с SpecFlow?

Question

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

На данный момент у меня есть один 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 1.3) определения шагов являются глобальными и не могут быть ограничены определенными функциями.

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

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

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

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

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

• Теги и теговые хуки: Вы можете пометить свои сценарии (например, @web) и определить в BeforeScenario-Hook, который должен работать только для сценариев с определенным тегом (т.е. [BeforeScenario ("web")]). См. Интеграцию Selenium в нашем примере с Книжным магазином: 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 3

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

Answer 4

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

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

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

Answer 5

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

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

BeforeTestRunScenario 
    BeforeFeature
        BeforeScenario
            BeforeScenarioBlock
                BeforeStep
                AfterStep
            AfterScenarioBlock
        AfterScenario
    AfterFeature
AfterTestRunScenario 

Answer 6

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

When I search for 'Barbados'

вместо

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

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