Writing BDD feature files shorter and cleaner

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 |

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                  |

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.

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.