Avoiding repeating yourself in Gherkin - cucumber

Question

So I've been using specflow for a while now and something has been bugging me.
This is an example of a scenario we are currently using:
Scenario: Select a region via selection button
When I select "Scotland" from Available Regions
And I click on the "Select One" button
Then Available Regions does not contain "Scotland"
And Selected Regions contains "Scotland"
Is there a away to avoid saying "Scotland" on almost every line ?
Or does it make it more readable and I should just stick with it ?

Answer 1

Before I attempt to answer your question, can I suggest you take a minute to go and read Dan North's Who's domain is it anyway.
So firstly I'd like to get rid of the line that says And I click on the "Select One" button, because I think that should implicitly be part of When I select "Scotland" from Available regions.
Now you have
Scenario: Select a region
When I select "Scotland" from Available Regions
Then Available Regions does not contain "Scotland"
And Selected Regions contains "Scotland"
And you could write it as
Scenario: Select a region
When I select "Scotland" from Available Regions
Then Available Regions does not contain the last selected region
And Selected Regions contains the last selected region
Is there much of a difference? Well probably not.
What I've found as I've spent more time with cucumber, is that it helps to refactor your scenarios as much as you refactor the code behind them. In C#/SpecFlow we could implement
Then Available Regions does not contain "Scotland"
with
[Then("Available Regions does not contain (.*)")]
public void ThenAvailableRegionsDoesNotContain(string region)
{
AvailableRegions.Contains(region).ShouldBeFalse();
}
and
Then Available Regions does not contain the last selected region
with
[Then("Available Regions does not contain the last selected region")]
public void ThenAvailableRegionsDoesNotContainLastSelectedRegion()
{
ThenAvailableRegionsDoesNotContain(LastSelectedRegion);
}
It honestly is up to you. Which dialect you prefer

Answer 2

Interesting example!
As others have stated, it's generally advised to avoid details of implementation in your scenarios - that's what the step definitions are for. But you know this already.
The question I'd then ask is: who are you proving this behaviour to? Who is interested in asserting that you can click a button or double click by means of a formal test? If your answer isn't "nobody", then perhaps this applies:
"When this scenario was written, you can imagine the stakeholder probably didn’t care much how ... As soon as we start introducing options ... the details ... suddenly become interesting ...
At this point I would expect this scenario to be augmented with some finer-grained, or lower-level, scenarios, each describing the different [options] we support. These new scenarios would be aimed at a different stakeholder."
From the comments on Dan North's "Whose Domain Is It Anyway?"
Perhaps you want the scenario written in both forms: one higher-level just demonstrating that the user can select the region for the business guys (how doesn't matter) and another two, for a different stakeholder showing the different options to do so.
So, once you've decided that what you're doing is worthwhile, I'd probably just repeat "Scotland" (a table for a single value is overkill here).
On a slightly different note, I also suggest:
Then Available Regions should not contain "Scotland"
And Selected Regions should contain "Scotland"

Answer 3

I'd recommend revising the title of this scenario. "Select a region" is not really telling you, what to expect from this example. It could be some complex behaviour that is triggered when you select a region, or a tiny UI detail such as the selected region moves from the available regions to the selected regions list.
If I understand your example correctly, it's the latter, so I'd suggest a title like:
Scenario: Selected region should be moved from available to selected regions
Having a more expressive title has IMHO to advantages:
1) You can quicker navigate and find relevant examples in your living documentation, when you are looking for a certain detail: reading an expressive title is always faster than reading the whole example and reverse engineering the intention of it.
2) For more complex scenarios (which this example seems not to be), an expressive title conveying the intention of the scenario helps the reader understanding the details of the scenario more quickly.
To make the scenario more interesting to read, I would combine the assertions into one step, as you actually want to assert that the selected item has been moved from the available to the selected list:
Scenario: Selected region should be moved from available to selected regions
When I select "Scotland" from "Available Regions"
Then "Scotland" should be moved from "Available Regions" to "Selected Regions"
I think this is pretty near to how I would explain this detail to somebody in a conversation. I wouldn't mind repeating "Scotland" here, although some people might prefer replacing "Scotland" with "the selected region", as AlSki already pointed out. It's a matter of taste and I usually try to listen what actual words were used during the conversation about the scenario, that should happen always before writing it down.
As a minor note I want to mention that I have the impression that this is a scenario concerning a pretty low-level UI detail. I would be much more interested, what higher level impact it has, when I select a specific region (if selecting a region has any specific business relevance at all). And if you really want to describe and automate validation of such a low-level UI detail in a scenario, I'd consider showing this also in how I phrase the scenario:
Scenario: Selected region should be moved from available to selected regions list
When I select "Scotland" from the "Available Regions" list
Then "Scotland" should be moved from the "Available Regions" to "Selected Regions" list
Of course I just assumed now, that you are describing a detail UI behaviour of a list in your scenario, as you didn't write about a list in your original scenario. If it is not about the UI, what you are describing, the scenario should be phrased differently to express this better.

Answer 4

While I agree with #AlSki that some refactoring is a good idea, you can use the Examples syntax to use the same value multiple times:
Scenario Outline: Select a region
Given do this "<value>"
And do that "<value>"
When we perform "<value>"
Then we get "<value>"
Examples:
| value |
| Scotland |
You can also add multiple entries into the table to run the same test many times with different values each time:
...
Examples:
| value |
| Scotland |
| England |
| Wales |
Here is an example with multiple values, which allows you to do things like:
Scenario Outline: Select a region
Given do this "<value>" with "<area>"
And do that "<value>"
When we perform "<value>"
Then we get "<result>"
Examples:
| value | area | result |
| Scotland | North | 40 |
| Scotland | South | 100 |
| England | West | 200 |
| England | North | 180 |