Geek Answers Handbook

Working with a few small changes in SpecFlow

Hello everyone. We are developing a web service that will be available through SOAP and REST (xml and JSon). Our specflow functions are basically the same: ie:

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, the REST / Xml interface, and the REST / JSon interface.

In a cucumber, you can run functions using -R to determine where the step files are, however in SpecFlow I have not yet found a way to create step files so that I have the same run of the function in different steps.

I would prefer not to write each script 3 times to change which implementation of the step to use.

So, two questions: 1) How can I run the function 3 times for 3 different interfaces that expect accurate scripts? 2) How can I select the correct steps file every time?

Solution (1) is likely to solve (2).

+4
source share
4 answers

My college gave us a well-working solution: Scenario:

 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, a test case is a function that takes two parameters: one for one and one for.

Running this script creates 3 unit tests, which I did after.

More information here: Managing groups of related scripts

+10
source

The only thing that comes to my mind is to use a script scheme, which allows you to define a family of scripts and then execute its variants, providing various parameters in the table.

But I'm not sure that it is justified to use a script scheme, which is mainly intended to change input options, and not to configure the infrastructure.

Another question is if SpecFlow is the right place to configure these steps, should these parts not be tested at a different level (infrastructure integration tests and unit tests for components), so Gherkin is only used for end-to-end acceptance testing. Some time ago, I would have found that SpecFlow is the wrong tool for such tests, but I can see that Gherkin has been used successfully at all levels, so maybe your question raises a good point about how SpecFlow (and Gherkin) can be accepted. to enable this type of testing without repeating the code.

+1
source

SpecFlow has a concept called tagging. You can decorate the step with a tag.

Unfortunately, you still need a script that will be shown three times, but with different @tags.

Then you set StepScopeAttribute in the method or class to say that this method / class is bound to a specific function / script / tag. Here is a sample project from the author:

https://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ScopedSteps

0
source

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 three separate interfaces.

However, I would question if your approach is reasonable. Assuming separate interfaces share the same business logic, is it likely that only one of the three will fail? It would be better to test a small number of key methods on all interfaces, and for most methods just select one interface for testing?

0
source

More articles:


All Articles