Gherkin "OR" syntax to reduce repetition with BDD

Question

Does anyone know of a way to achieve this or do they think it's a good idea. To have an OR style syntax in Gherkin for reducing repetition but maintaining human readability (hopefully). I'm thinking of cases where clause combinations are expanded with every combination of multiple OR statements. e.g.

Scenario: TestCopy
  Given Some text is selected
  When The user presses Ctrl + C
    OR the user right clicks and selects copy
    OR the user selects Edit + Copy
  Then the text is copied to the clipboard

This would run as 3 tests each with the same given and then but with one When from the OR set. I guess this could have been acheived using a template with a place holder for the When clause but I think this is more readable and could allow the OR to be used in the Given as well to produce n x m tests. With the outline you would still need n x m rows.

• Is there a better way to do this
• Is it better practice to explicitly copy and paste (I'm thinking maintenance could get messy)
• Do other frameworks support this (I think with FIT you could write a custom table but again this seems like overhead)

Thanks.

Solution 1

You can generatd multiple tests from one scenario with Scenario Outlines:

Scenario Outline: TestCopy
  Given Some text is selected
  When <Copy operation executed>
  Then the text is copied to the clipboard

Examples: 
    | Copy operation executed                |
    | The user presses Ctrl + C              |
    | the user right clicks and selects copy |
    | the user selects Edit + Copy           |

In a Scenario Outline you basically create a template which is filled in the with the provided Examples.
For the the above example Specflow will generate 3 tests with the same Given and Then and with the 3 different Whens:

When The user presses Ctrl + C
When the user right clicks and selects copy
When the user selects Edit + Copy

Solution 2

It's not recommended to use this detail level (pressing these keys, right clicking) on the scenarios. This makes them, as you realize, lengthy and repetitive. Also, that's usually not the information the stakeholders would need or want anyway.

The best would be to hide the implementation details on the step definitions. Your scenario would be something like:

Scenario: TestCopy
  Given some text is selected
  When the user copies the selected text
  Then the selected text is copied to the clipboard

And the different ways of copying the text would go to the 3rd step definition.

Solution 3

As for the n x m scenario, I feel like that when you want to do that, you're probably cuking it wrong.

You didn't give an explicit example, but suppose you want something like:

Given A block of text is selected
OR An image is selected
OR An image and some text is selected
When The user presses Ctrl + C
OR the user right clicks and selects copy
OR the user selects Edit + Copy

Writing your Then clause will be a nightmare.

Instead, try two tests... first, as suggested by @nemesv - but with "text selection" replaced by a generic "selection".

Scenario Outline: TestCopy
  Given I have made a selection
  When <Copy operation executed>
  Then my selection is copied to the clipboard

Examples: 
  | Copy operation executed                |
  | The user presses Ctrl + C              |
  | the user right clicks and selects copy |
  | the user selects Edit + Copy           |

You can then write a one or more additional tests to deal with "what makes a valid selection" - and this will probably by a feature that you use independent of the copy function - for example, what happens when you make a selection and hit delete... or ctrl-v... or drag and drop?

You don't want to go down the road of multiplying all the valid ways of making a selection against all the valid actions you can take when you've got one.

Comments

[Marcus Hammarberg]

Totally agree with @Marcelo here! Don't write about HOW the system is implemented in order to accomplish WHAT the user need. Try to find a higher level concept such as the "user copies the selected text" above. Much better!

[Ben Smith]

@MarcusHammarberg I too have been taught to write scenarios using "What" as opposed to "How". However, if there is more that one way to execute an action in a system (in this case copying text), then how should these different options be tested using SpecFlow? Hence why I think that having a test which iterates through the different options seems right.