Learn about Gherkin Scripting in of our How-To-Guide on applying Cucumber to lead your agile testing team down the path to automation.

Blog four of a series. In the 2000s, Dan North created a software development process call Behavior-Driven Development (BDD). In his quest to “find a simple and elegant way in Ruby to describe behavior at the application level,” Dan North created RBehave: a story-level BDD framework for Ruby. It was in this framework that the Gherkin scripting format was born. At a basic level, Gherkin Scripts connect the human concept of cause and effect to the software concept of input/process/output. The input is the Given step(s); the process is the When step(s); the output is the Then step(s). All scripts, regardless of where they are written or for what system they are written to test, should follow this same format. Or at least have each of these three parts.

Given

The purpose of Given steps is to put the system in a known state before the user (or external system) starts interacting with the system (in the When steps). Some people call the Given steps “Preconditions to the Action.” It is also a common place for data setup. Since no functionality should be changing in the Given step, you should rarely have an error in the Given steps. Some Examples:

When

With the system now in the state we need it to be, we can execute the change. The purpose of the When steps are to describe the key action the user performs. These are the MONEY steps. Or, in other words: the steps that the business is paying you to analyze, build and test. Some examples:

Then

The Then step(s) are the expected results of the When step(s). Its purpose is to observe the outcome of the previous action. Many times the outcome is some kind of output: something that comes out of the system, which has business value. This might be a report, a message, navigation to a page, etc. Other times it might be data in a database that has changed or the output from a web service. Either way, it can be quantified. Some examples:

The Language of the Domain

An important aspect of Gherkin scripts is that they are written using the language, terms and definitions of the domain. It has to be “stakeholder-readable.” Stated simply, if a script is written for business acceptance, it should be written so the business users can understand it and follow what is happening. If a script is written for an integration test of a web service or a database conversion validation, it should be written so the developers and testers can understand it and follow what is happening. Understanding which domain you are in is very important when writing a Gherkin script. Gherkin scripting seems simple: some Given steps to set the test up, a When action step to do something, and a Then step to observe the results of the action. But don’t be deceived by their simplicity. Getting a user to the action is not always easy. And business users might not always be clear about the results they expect from the action. The power of a well-written Gherkin script is that it facilitates the conversation to make sure it is right.

It might seem like just another tool in an agile tester’s tool belt. The reality is that Gherkin scripts can be one of the best collaboration tools a tester has.