处理 SpecFlow 中的多个细微变化
大家好 我们正在开发一项可通过 SOAP 和 REST（xml 和 JSON）使用的 Web 服务。我们的specflow功能大部分是相同的，即：
Scenario: There are at least 3 radio Channels
Given The test server is up and running
And The previously obtained channel list is reset
When I request a list of radio channels
Then the resulting deliveryPackage contains a list of at least 3 items
所有这些功能都需要针对SOAP接口、REST/Xml接口和REST/JSon接口进行测试。
在 Cucumber 中，可以使用 -R 来指示步骤文件所在的位置来运行功能，但是在 SpecFlow 中，我还没有找到围绕步骤文件的方法，以便我可以让相同的功能运行不同的步骤。
我宁愿不必将每个场景编写 3 次才能更改要使用的步骤实现。
那么，两个问题： 1) 如何为 3 个不同的接口运行一个功能 3 次，并且场景完全相同？ 2）如何每次选择正确的步骤文件？
解决（1）可能会解决（2）。
Hi all
We are developing a web service that will be available through SOAP and REST (xml and JSon). Our specflow features are mostly the same, i.e:
Scenario: There are at least 3 radio Channels
Given The test server is up and running
And The previously obtained channel list is reset
When I request a list of radio channels
Then the resulting deliveryPackage contains a list of at least 3 items
All of these features need to be tested for the SOAP interface, for the REST/Xml interface, and for the REST/JSon interface.
In cucumber, it is possible to run the features using -R to dictate where the steps files are located, however in SpecFlow, I have not yet found a way around the steps files, so that I can have the same feature run different steps.
I would rather not have to write each scenario 3 times in order to change which step implementation to use.
So, two questions:
1) How do I run a feature 3 times for 3 different interfaces that expect the exact same scenarios?
2) How do I choose the correct step file each time?
Solving (1) will probably solve (2).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我的一位同事给了我们一个很好的解决方案：场景概要：
在幕后，测试用例是一个接收两个参数的函数，一个用于，一个用于 .
运行这个场景会产生 3 个单元测试，这正是我所追求的。
更多信息请参见：管理相关场景组
A collegue of mine gave us a well working solution: Scenario Outlines:
Behind the scenes, the test case is a function that receives two parameters, one for and one for the .
Running this scenario produces 3 unit tests, which is what I was after.
More info here: Managing groups of related scenarios
我唯一想到的是使用场景大纲，它允许定义一系列场景，然后通过在表中提供不同的参数来执行它的变体。
但我不确定这是否合理使用场景大纲，该大纲主要针对输入的变化，而不是基础设施设置的变化。
另一个问题是，如果 SpecFlow 是配置这些步骤的正确位置，那么这些细节不应该在不同级别上进行测试（基础设施集成测试和组件单元测试），因此 Gherkin 仅用于端到端用例验收测试。不久前，我坚持认为 SpecFlow 对于此类测试来说是一个错误的工具，但我看到 Gherkin 在所有级别上都得到了成功的使用，所以也许你的问题提出了一个很好的观点，即如何采用 SpecFlow（和 Gherkin）来实现这种测试无需重复代码即可进行测试。
The only thing that comes to my mind is using scenario outline that allows defining a family of scenarios ones and then execute variations of it by supplying different parameters in a table.
But I am not sure this is justified use of scenario outline that is mostly to target variations in input, not in infrastructure setup.
Another question if SpecFlow is a right place to configure such steps, shouldn't these details be tested on a different level (infrastructure integration tests and unit tests for components), so Gherkin is only used for end-to-end use case acceptance test. Some time ago I would instist that SpecFlow is a wrong tools for such tests, but I see that Gherkin is successfully used on all levels, so perhaps your question raises a good point of how SpecFlow (and Gherkin) can be adopted to enable this kind of testing without repeating code.
SpecFlow 具有一个称为标记的概念。您可以使用标签来装饰步骤。
不幸的是，您仍然需要该场景出现三次，但使用不同的@标签。
然后，您可以在方法或类上设置
StepScopeAttribute来表示该方法/类的范围仅限于特定功能/场景/标签。作者有一个示例项目：https://github.com /techtalk/SpecFlow/tree/master/Tests/FeatureTests/ScopedSteps
SpecFlow features a concept called tagging. You can decorate a step with a tag.
Unfortunately, you will still need the scenario featured three times, but with different @tags.
You then set the
StepScopeAttributeon the method or class to say that this method/class is scoped to a particular feature/scenario/tag. There is a sample project here from the author:https://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ScopedSteps
怎么说呢：
每个步骤定义都可以包含三个单独的接口。
但是，我会质疑你的做法是否明智。假设不同的接口共享相同的业务逻辑，实际上是否有可能这三个接口中只有一个会失败？跨所有接口测试少量关键方法，而对于大多数方法只选择一个接口进行测试，也许会更好吗？
How about saying:
Each step definition can include the three separate interfaces.
However, I would question if your approach is wise. Assuming that the separate interfaces share the same business logic, is it actually likely that only one of the three would fail? Would it perhaps be better to test a small number of key methods across all interfaces, and for the majority of methods just pick one interface to test against?