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
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.
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.
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.