Writing BDD feature files shorter and cleaner - bdd

Question

I have s lot of scenarios that are identical, they only differs by data which are passed to them.
This is example:
Feature: Linking facts from a report into Excel document
In order to link facts to an Excel document
As an user having access to report
I want to click on fact's value in the report
Scenario: Any uri item
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell C2
And I click on the value in 2 column of the row entitled any uri item
Then Excel cell C2 should contain value some internet address
Scenario: Base64 binary item
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell F3
And I click on the value in 2 column of the row entitled base64 binary item
Then Excel cell F3 should contain value asdf
Scenario: Boolean item
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell J3
And I click on the value in 2 column of the row entitled boolean item
Then Excel cell J3 should contain value true
I would like to shorten this to look something like following:
before scenario:
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
scenario:
When I click on excel cell XX
And I click on the value in YY column of the row entitled ZZ
Then Excel cell YY should contain value WW
and than some table data, like:
| XX | YY | ZZ | WW |
| C2 | 2 | any uri item | some internet address |
| F3 | 2 | base64 binary item | asdf |
| J3 | 2 | boolean item | true |
I found an solution.
There is an scenario outline with this ability.
Scenario Outline: display label in selected language
Given I am logged as <username> with <password>
And I have clicked on <button> button
Then result should be some result
Examples:
| username | password | button |
| john | doe | first |
| foo | bar | second |

Answer 1

You could use Scenario Outline instead of Scenario. Your example would look something like this:
Scenario Outline:
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
When I click on excel cell '<Cell>'
And I click on the value in '<Column>' column of the row entitled '<Row>'
Then Excel cell '<Cell>' should contain value '<CellValue>'
Examples:
| Cell | Column | Row | CellValue |
| C2 | 2 | any uri item | some internet address |
| F3 | 2 | base64 binary item | asdf |
| J3 | 2 | boolean item | true |

Answer 2

This is a very interesting question and I have spent some time researching what I call "data driven Specifications". This is partly inspired by the "row-test" or "data-driven-test" features that many common test frameworks offer.
Not that I use the terms "Scenario" and "Specification" synonmous, however I prefer the latter.
Similar to a normal unit test, a BDD specification is composed of three parts. A common template used is the "Given X When Y Then Z" formula. What you have discovered is that for a lot of your specifications the "X" part stays the same. Whenever I encounter such a situation, I try to create a Fixture class to abstract this. For example, one of those classes might be a LoggedInUserFixture which sets up a logged in user and makes it available to the test.
Very often, you'll find the need to compose this fixture with other fixtures, to create the setting for your specification. For example you may need a LoggedInUserFixture and a UserWithSampleProjectSelected for a single Specification. The easiest way to do this is to create another fixture class that will setup its child fixtures and makes them individually available to your test.
I am still resisting the urge to extract a common pattern for composing fixtures and make a test framework support this.
To come back to the suggestion to use data to drive specifications, I think it is a valid and useful patterns, I usually make the data drive my fixture creation (the fixture has an appropriate constructor for data injection then). See SubSpec's Theorie feature for details.

Answer 3

This answer is 8 years too late, but Gherkin has a way of eliminating this duplication. It's called the Scenario Background:
Feature: ...
In order to ...
As a ...
I want to ...
Background:
Given common step 1
And common step 2
Scenario: A
When ...
Then ...
Scenario: B
When ...
Then ...
More specifically applied to your situation:
Feature: Linking facts from a report into Excel document
In order to link facts to an Excel document
As an user having access to report
I want to click on fact's value in the report
Background:
Given I am logged as admin with admin
And I have selected Sample Project
And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
Scenario: Any uri item
When I click on excel cell C2
And I click on the value in 2 column of the row entitled any uri item
Then Excel cell C2 should contain value some internet address
Scenario: Base64 binary item
When I click on excel cell F3
And I click on the value in 2 column of the row entitled base64 binary item
Then Excel cell F3 should contain value asdf
Scenario: Boolean item
When I click on excel cell J3
And I click on the value in 2 column of the row entitled boolean item
Then Excel cell J3 should contain value true
The three common Given steps are moved into the Background, and then each of your scenarios start out with a When.
Nice and tidy.
The reason this is preferable to a scenario outline is because you are dealing with parsing multiple kinds of data. Presumably there is some parsing logic behind the scenes, and parsing each data type could break in different ways during regression testing. Each test should only have one reason to fail, and your original scenarios properly capture that.