How do you counteract the anti-pattern of BDD scripts in Specflow?

Question

This is an example of one of our acceptance tests:

Feature: Add an effect to a level In order to create a configuration As a user I want to be able to add effects to a level Scenario: Add a new valve effect to a level Given I have created a level named LEVEL123 with description fooDescription And I am on the configuration page When I click LEVEL123 in the level tree And I expand the panel named Editor Panel And I click the Add Valve Effect button And the popup named ASRAddVal appears And I click the Add new button And I fill in these vertical fields | field name | value | | Name | Effect123 | Then I should see the following texts on the screen | text | | Effect added : EFFECT123 | 

We feel that this has been enriched a bit, and we want to hear how you reduce the steps in Specflow. From what I have read so far, it is not recommended to create certain steps without reuse, so what is considered “best practice” when doing this in SpecFlow?

Update:

I'm trying to say that I found out that you should try to create common steps in order to reuse them in several tests. One way to do this is to parameterize your steps, for example: "Given that I created a level called ..", but parameterization also introduces verbosity. I want to end up with something like Brian Oakley in my answer, but I just can't figure out how I can do this without creating steps that are very specific to each test. This again means that I will have many steps that will reduce maintainability. It seems that SpecFlow has some way of defining abstract steps by creating a file that inherits a base class called “Steps”, but this still introduces new steps.

So, we summarize things; show me a good completion approach with Brian Oklis's answer that can be catered for.

Answer 1

I would simplify it like this:

 Scenario: Add a new valve effect to a level Given I have created a new level When I add a new valve effect with the following values | field name | value | | Name | Effect123 | Then I should get an on-screen confirmation that says "Effect added: Effect123" 

The way I approached this problem was to imagine that you are completely redesigning the user interface. Will the test still be used? For example, the test should work even if the redesign does not have the Add button, or you no longer use the pop-up window.

Answer 2

You can try to formulate them in general terms and use parameters.

 Given i have create a new: Level 

':' only so that you can identify the parameter. This means that you will have one common entry point for the step that should create something new. Its step by step to look at the level parameter and create a new level

Also try coming up with a name translation that everyone can use. It should be easy for you to know what steps have already been created so that you do not get duplicate similar steps.

Answer 3

May I suggest that perhaps the code you are testing should pass unit tests. It is possible that you mean “specific test” - these are separate unit tests that do not fall under your acceptance tests.

Just a thought :)