{"id":5631,"date":"2017-12-14T20:20:22","date_gmt":"2017-12-14T20:20:22","guid":{"rendered":"http:\/\/putridparrot.com\/blog\/?p=5631"},"modified":"2017-12-14T20:20:22","modified_gmt":"2017-12-14T20:20:22","slug":"the-gherkin-language","status":"publish","type":"post","link":"https:\/\/putridparrot.com\/blog\/the-gherkin-language\/","title":{"rendered":"The Gherkin language"},"content":{"rendered":"

Gherkin is a DSL used within BDD development. It’s used along with Cucumber which processes the DSL or in the case of .NET we can use tools such as SpecFlow (which I posted about a long time back, see Starting out with SpecFlow<\/a>) to help generate files and code.<\/p>\n

Gherkin allows us to create the equivalent of use cases in a human readable form, using a simple set of keywords and syntax which can then be use to generate a series of method calls to undertake some action and assertion. <\/p>\n

Getting started<\/strong><\/p>\n

We can use a standard text editor to create Gherkin’s feature files, but if you prefer syntax highlighting and intellisense (although this language we’re using is pretty simple) then install SpecFlow into Visual Studio or add a Gherkin syntax highlighter into VSCode (for example) or just use your preferred text editor.<\/p>\n

I’m going to create a feature file (with the .feature extension) using the SpecFlow item template, so we have a starting point which we can then work through. Here’s the file generated code<\/p>\n

\r\nFeature: Add a project\r\n\tIn order to avoid silly mistakes\r\n\tAs a math idiot\r\n\tI want to be told the sum of two numbers\r\n\r\n@mytag\r\nScenario: Add two numbers\r\n\tGiven I have entered 50 into the calculator\r\n\tAnd I have entered 70 into the calculator\r\n\tWhen I press add\r\n\tThen the result should be 120 on the screen\r\n<\/pre>\n
What we have here is a Feature<\/em> which is meant to describe a single piece of functionality within an application. The feature name should be on the same line as the Feature:<\/em> keyword.<\/p>\n
In this example, we’ve defined a feature which indicates our application will have some way to add a project within our application. We can now add an optional description, which is exactly what the SpecFlow template did for us. The Description may span multiple lines (as can be seen above with the lines under the Feature<\/em> line being the description) and should be a brief explanation of the specific feature or use case. Whilst the aim is to be brief, it should include acceptance criteria and any relevant information such as user permissions, roles or rules around the feature. <\/p>\n
Let’s change our feature text to be a little meaningful to our use case.<\/p>\n
\r\nFeature: Add a project\r\n\r\n\tAny user should be able to create\/add a new project\r\n\tas long as the following rules are met\r\n\r\n\t1. No duplicate project names can exist\r\n\t2. No empty project names should be allowed\r\n<\/pre>\n
I’m sure with a little thought I can come up with more rules, but you get the idea. <\/p>\n
The description of the feature is a useful piece of documentation and can be used as a specification\/acceptance criteria.<\/p>\n
Looking at the generated feature code, we can see that SpecFlow also added @mytag<\/em>. Tags allow us to group scenarios. In terms of our end tests, this can be seen as a way of grouping features, scenarios etc. Multiple tags may be applied to a single feature or scenario etc. for example<\/p>\n
\r\n@project @mvp\r\nFeature: Add a project\r\n<\/pre>\n
I don’t need any tags for the feature I’m implementing here, so I’ll delete that line of code.<\/em><\/p>\n
The Scenario<\/em> is where we define each specific scenario of a feature and the steps to be taken\/expected. The Scenario<\/em> takes a similar form to a Feature<\/em>, i.e. Scenario: and then a description of the context. <\/p>\n
Following the Scenario<\/em> line, we then begin to define the steps that make up our scenario, using the keywords Given<\/em>, When<\/em>, Then<\/em>, And<\/em> and But<\/em>. <\/p>\n
In unit testing usage, we can view Given<\/em> as a precondition or setup. When<\/em>, And<\/em> and But<\/em> as actions (where But<\/em> is seen as a negation) and this leaves Then<\/em> as an assertion.<\/p>\n
Let’s just change to use some of these steps in a more meaningful manner within the context of our Scenario<\/em><\/p>\n
\r\nScenario: Add a project to the project list\r\n\tGiven I have added a valid project name\r\n\tWhen I press the OK button\r\n\tThen the list of projects should now include my newly added project\r\n<\/pre>\n
Eventually, if we generate code from this feature file, each of these steps would get turned into a set of methods which could be used as follows<\/p>\n