使用 SpecFlow 定义特征范围的步骤？
我正在使用 SpecFlow 进行一些 BDD 风格的测试。我的一些功能是 UI 测试，所以他们使用 WatiN。有些不是 UI 测试，所以它们不是。
目前，我有一个 StepDefinitions.cs 文件，涵盖了我的所有功能。我有一个 BeforeScenario 步骤来初始化 WatiN。这意味着我的所有测试都会启动 Internet Explorer，无论是否需要。
SpecFlow 中是否有任何方法可以将特定的特征文件与一组特定的步骤定义相关联？或者我是从错误的角度来处理这个问题的？
I'm using SpecFlow to do some BDD-style testing. Some of my features are UI tests, so they use WatiN. Some aren't UI tests, so they don't.
At the moment, I have a single StepDefinitions.cs file, covering all of my features. I have a BeforeScenario step that initializes WatiN. This means that all of my tests start up Internet Explorer, whether they need it or not.
Is there any way in SpecFlow to have a particular feature file associated with a particular set of step definitions? Or am I approaching this from the wrong angle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您使用标签，有一个简单的解决方案可以解决您的问题。
首先标记您的功能文件以指示特定功能需要 WatiN，如下所示：
然后使用指示标记的属性来装饰 BeforeScenario 绑定：
这样，只有使用 WatiN 的功能才会调用此 BeforeScenario 方法。
There is a simple solution to your problem if you use tags.
First tag you feature file to indicate that a particular feature needs WatiN like that:
And then decorate the BeforeScenario binding with an attribute that indicates the tag:
This BeforeScenario method will then only be called for the features that use WatiN.
目前（在 SpecFlow 1.3 中）步骤定义是全局的，不能限定于特定功能。
这是设计为与 Cucumber 具有相同行为的。
我在黄瓜组上问了同样的问题：
http://groups .google.com/group/cukes/browse_thread/thread/20cd7e1db0a4bdaf/fd668f7346984df9#fd668f7346984df9
基线是，所有功能文件定义的语言也应该是全局的（整个应用程序的一种全局行为）。因此，应避免将定义范围限定为功能。就我个人而言，我还没有完全相信这一点......
但是，您仅针对需要 UI 集成的场景启动 WatiN 的问题可以通过两种不同的方式解决：
标签和标记挂钩：您可以标记您的场景（即使用@web) 并定义一个 BeforeScenario-Hook ，它只应针对具有特定标签的场景运行（即 [BeforeScenario("web")]）。请参阅我们的 BookShop 示例中的 Selenium 集成：http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs< /p>
Currently (in SpecFlow 1.3) step-definitions are global and cannot be scoped to particular features.
This is by design to have the same behavior as Cucumber.
I asked the same question on the cucumber group:
http://groups.google.com/group/cukes/browse_thread/thread/20cd7e1db0a4bdaf/fd668f7346984df9#fd668f7346984df9
The baseline is, that the language defined by all the feature files should also be global (one global behavior of the whole application). Therefore scoping definitions to features should be avoided. Personally I am not yet fully convinced about this ...
However your problem with starting WatiN only for scenarios that need UI-Integration can be solved in two different ways:
Tags and tagged hooks: You can tag your scenarios (i.e with @web) and define ina BeforeScenario-Hook that only should run for scenarios with a certain tag (i.e. [BeforeScenario("web")]). See the Selenium integration in our BookShop example: http://github.com/techtalk/SpecFlow-Examples/blob/master/ASP.NET-MVC/BookShop/BookShop.AcceptanceTests.Selenium/Support/SeleniumSupport.cs
We often completely separate scenarios that are bound to the UI and scenarios that are bound to a programmatic API (i.e controller, view-model ...) into different projects. We tried to illustrate this in our BookShop example: http://github.com/techtalk/SpecFlow-Examples/tree/master/ASP.NET-MVC/BookShop/ .
看看这个（SpecFlow 1.4 中的新功能）：https://github.com/techtalk/ SpecFlow/wiki/作用域绑定
Check this out (new feature in SpecFlow 1.4): https://github.com/techtalk/SpecFlow/wiki/Scoped-Bindings
我最初假设步骤文件与特定的功能文件相关联。当我意识到事实并非如此时，它帮助我改进了所有 SpecFlow 代码和功能文件。我的功能文件的语言现在较少依赖于上下文，这导致了更多可重用的步骤定义和更少的代码重复。现在，我根据一般相似性而不是根据它们的功能来组织我的步骤文件。据我所知，没有办法将步骤与特定功能关联起来，但我不是 SpecFlow 专家，所以不要相信我的话。
如果您仍然希望将步骤文件与特定功能文件关联，只需为它们提供相似的名称即可。即使步骤代码仅对该功能有意义，也无需强制它仅适用于该功能。这是因为，即使您碰巧为不同的功能创建了重复的步骤，它也会将其检测为不明确的匹配。可以在 App.config 文件中指定不明确匹配的行为。看
http://cloud.github.com/downloads/techtalk/SpecFlow/ SpecFlow%20Guide.pdf
有关 App.config 文件的更多详细信息。默认情况下，会检测到不明确的匹配并将其报告为错误。
[编辑]：
实际上，这种工作方式存在问题（仅在您的脑海中将步骤文件与功能文件相关联）。当您添加或修改 .feature 文件并使用之前使用过的相同措辞，并且忘记为其添加步骤，但您没有注意到这一点，因为您之前已经为该措辞创建过一次步骤时，就会出现问题，并且它是以上下文相关的方式编写的。此外，我不再相信不将步骤文件与功能文件关联的有用性。我认为大多数客户不太擅长以独立于上下文的方式编写规范。这不是我们通常写作、谈话或思考的方式。
I originally assumed that a step file was associated with a particular feature file. Once I realized this was not true it helped me to improve all my SpecFlow code and feature files. The language of my feature files is now less context depended, which has resulted in more reusable step definitions and less code duplication. Now I organize my step files according to general similarities and not according to which feature they are for. As far as I know there is no way to associate a step with a particular feature, but I am not a SpecFlow expert so don't take my word for it.
If you still would like to associate your step files with a particular feature file, just give them similar names. There is no need for it to be forced to only work for that feature even if the step code only makes sense for that feature. This is because even if you happen to create a duplicate step for a different feature, it will detect this as an ambiguous match. The behavior for ambiguous matches can be specified in an App.config file. See
http://cloud.github.com/downloads/techtalk/SpecFlow/SpecFlow%20Guide.pdf
for more details the about App.config file. By default ambiguous matches are detected and reported as an error.
[edit]:
Actually there is a problem with working this way (having step files associated with feature files in your mind only). The problem comes when you add or modify a .feature file and use the same wording you have used before, and you forget to add a step for it, but you don't notice this because you already created a step for that wording once before, and it was written in a context sensitive manner. Also I am no longer convinced of the usefulness of not associating step files with feature files. I don't think most clients would be very good at writing the specification in a context independent manner. That is not how we normally write or talk or think.
解决方案是实施 Tags &与 Web 相关或与代码中的控制器/核心逻辑相关的测试场景的范围绑定。
并将每个场景的范围深入到下面提到的执行之前/之后的任何一个
Solution for this is to implement Tags & Scoped Binding with the test scenario which is related to Web or related to Controller / Core logic in code.
And drill down the scope for each scenario to any of the below mentioned Before / After execution
还可以考虑使用与实现无关的 DSL 以及特定于实现的步骤定义。例如，使用
而不是
通过实现多个步骤定义程序集，相同的场景可以通过不同的接口执行。我们使用这种方法使用相同的场景来测试 UI、API 等。
Also consider using implementation-agnostic DSL along with implementation-specific step definitions. For example, use
instead of
By implementing multiple step definition assemblies, the same Scenario can execute through different interfaces. We use this approach to test UI's, API's, etc. using the same Scenario.