Dealing with multiple, slight variations in SpecFlow

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 th开发者_JS百科e 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).

A collegue of mine gave us a well working solution: Scenario Outlines:

Scenario Outline: Channels on different protocols
Given The test server is up and running
And The previously obtained channel list is reset
When I request a list of radio channels for the <protocol> and <binding>
Then the resulting deliveryPackage contains a list of  at least 3 items
Scenarios: 
| protocol | binding                          |
| XML      | BasicHttpBinding_IProgramService |
| JSON     | BasicHttpBinding_IProgramService |
| SOAP     | CustomBinding_IProgramService    |

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

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 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 StepScopeAttribute on 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:

When I request a list of radio channels for JSON, XML and SOAP
Then the corresponding resulting deliveryPackages contains a list of  at least 3 items

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?