A little bit of Gherkin

I have been using Spec Flow for the last few months as my feature specification framework, but sometimes the output I want to assert can be very repetitive, a simple example of this the string calculator kata.

Each part of the add feature specification is actually simply checking the return value given a specified input string.

using a traditional spec flow scenario specification it would look a bit like this

  1. Feature:Calculator Kata
  2. As a developer   
  3. I want practice my craft
  4. So that I become a better developer
  6. Scenario: string calculator add method with input containing "1"
  7.   Given the input stirng contains 1
  8.   When add is called
  9.   Then the result is 1
  11. Scenario: string calculator add method with input containing "1,2"
  12.   Given the input stirng contains 1,2
  13.   When add is called
  14.   Then the result is 3
  16. Scenario: string calculator add method with input containing "1,2,3"
  17.   Given the input stirng contains 1,2,3
  18.   When add is called
  19.   Then the result is 6
  21.   etc……


lots of repeated code here, even using a regex to simplify the step definitions our feature file is going to get very long and difficult to maintain.

To help with just this sort of problem, Spec Flow supports the gherkin table construct this allows us to define the scenario steps separately from the data required by the steps, in this case our data is the input string “<input> and expected result <output>.

The steps are defined by a scenario outline with place holders for each of the required data values, and the data itself is defined in an examples table structure with a column for each place holder separated by the “|” pipe character.

  1. Scenario Outline: String calculator add method with valid input
  2.      Given the input stirng contains ‘<input>’
  3.      When add is called
  4.      Then the result is ‘<output>’
  6.      Examples:
  7.      | input    | output |
  8.      |          | 0      |
  9.      | 1        | 1      |
  10.      | 2        | 2      |
  11.      | 1,2      | 3      |
  12.      | 1,2,3    | 6      |
  13.      | 1!2,3    | 6      |
  14.      | //;!1;2  | 3      |


When the scenario is run it loops around replacing the place holders with each row of data, until either there is an error (fail) or it runs out of data (success).

The step definitions for the scenario outline are exactly the same as for a normal step definition, using a regex to extract the values passed by the framework, and handing them into the method definition as parameters.

  1. [Binding]
  2. public class CalculatorAddSteps
  3. {
  4.     [Given(@"the input stirng contains ‘(.*)’")]
  5.     public void GivenTheInputStirngContains(string inputString)
  6.     {            
  7.     }
  9.     [When(@"add is called")]
  10.     public void WhenAddIsCalled()
  11.     {
  12.     }
  14.     [Then(@"the result is ‘(.*)’")]
  15.     public void ThenTheResultIs(int expected)
  16.     {            
  17.     }
  18. }


Using the table structure is a very powerful way of displaying the data required by a specification, and controlling the number of scenarios that need to be written.


About Duncan Butler

Trying to be a very agile software developer, working in C# with Specflow, Nunit and Machine Specifications, and in the evening having fun with Ruby and Rails
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s