4 posts tagged with "Gherkin"

Gojko Adzic wrote his award-winning book, Specification By Example, 11 years ago. Last year, he ran an online poll to determine the most popular format for expressing examples and found that Given/When/Then received 71% of the votes.

Gherkin is probably the reason for this win, because:

• Given/When/Then are the core keywords of Gherkin
• Gherkin is the structured syntax understood by automation tools such as Cucumber
• Cucumber is a widely downloaded, open-source tool, available on numerous platforms

So, it might be fair to say that when it comes to documenting and automating examples, “Gherkin rules.” That is not what this article is about.

Over the holidays you voted for different ways to organise feature files. This article shows the results of the survey, an analysis of the votes, and some general ideas on how to organise your living documentation.

Gojko Adzic has been running a series of challenges called #GivenWhenThenWithStyle. This is my solution to challenge #16. You should definitely check out the rest of the challenges and their solutions.

Gáspár Nagy and I have written in more detail about writing and organising feature files in our new book, Formulation.

The winner is…​

Gojko Adzic is running a regular challenge called #GivenWhenThenWithStyle and last month’s topic was how to specify relative time periods. In his “solution” article, he disagreed with the majority of challenge respondents, favouring the use of a long scenario outline containing actual dates.

I have a different take to Gojko, that is more in line with the community response. This article describes my approach – but you’d be advised to read Gojko’s original posts first (and subscribe to the challenge).

Over the years that we have been using Gherkin, our approach to writing scenarios has evolved. Because Gherkin is very close to natural language it's very easy to learn, but just like writing reports or stories, it takes practice to do it well. There are three main goals that we try to keep in mind when writing scenarios:

• Scenarios should be thought of as documentation, rather than tests.
• Scenarios should enable collaboration between business and delivery, not prevent it.
• Scenarios should support the evolution of the product, rather than obstruct it.

The following six principles work together to support these goals. To make them easier to remember, we've arranged it so that the first letter of each principle makes up an acronym, BRIEF, which is itself the sixth principle.