Dealing with multiple, slight variations in SpecFlow

Question

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).

Answer 1

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

Answer 2

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.