Our recent blog post explained what the 3 Amigos sessions were and the benefits this can bring to a development team. The premise of the concept suggests that to really build a shared understanding, different perspectives need a common way to devise requirements and document them in a manner accessible to both technical and non-technical project members. This is where Behaviour Driven Development and Gherkin Syntax come in.
Let’s start with Behaviour Driven Development or BDD as it is commonly called. BDD is essentially a framework for thinking about software and specific requirements that we might expect the software to exhibit in certain scenarios or examples. Due to this, you may have heard it referred to as Specification by Example. To illustrate let’s take the concept of a simple login form with separate fields such as username, password and a submit button. If we wanted to think about this in terms of behaviour, the first step would be to try and think of all the scenarios or examples in which a user might interact with this login form. A quick brainstorm of examples might produce something like this…
Scenario 1: User enters correct details and clicks submit
Scenario 2: User enters correct username and incorrect password and then clicks submit
Scenario 3: User enters incorrect username and correct password and then clicks submit
Scenario 4: User clicks submit with empty username and password fields
This list above is not necessarily exhaustive but illustrates the concept of scenarios and their usefulness in terms of thinking about the login story we are implementing.
The point here is to take these examples and then think about how the software should behave in each scenario. This is Behaviour Driven Development.
Once the team has done an initial brainstorm in terms of scenarios, the next step is to translate these scenarios into a format accessible to the whole team regardless of technical understanding. The point here is that business stakeholders, product owners, developers, testers or designers understand the story and its expected output. This is where Gherkin Syntax can play a useful role.
Gherkin Syntax is basically a format for expressing software behaviour using a convention known as ‘Given, When, Then.’ We use this convention when we flesh out our scenarios. In abstract terms it looks something like this…
GIVEN some initial state
WHEN an action is performed
THEN this happens
Let's try this out on one of our examples from earlier.