I often introduce Gherkin to teams when I work with them. Naturally they then want to know why. So I think it's time I write that down.

Let's start with a brief description of what it is. Gherkin is a formal language (just like programming languages are formal languages) which is used to capture specifications is plain spoken language. It describes features using scenarios which in turn are made up of constructs like given, when and then.

This helps people to put a thing, whatever that think may be, into a context of what is before (given), what are we doing (when), what will come after. Often when new functions and features are requested by stakeholders they forget that there are a before, during and after. It's often just "Wouldn't it be great if our software can do this!".

Whit such a requirement passing through it's not very likely that the programmer will pick up on any issues. If there is a business analyst they should, but I've seen this fail as often as not. And the same is unfortunately true for testers too. Especially if the stakeholder in question is someone with a lot of power, like a C-level exec.

Using Gherkin we Force our self to think through things in a scenario. Where we first set the stage (given), we then do stuff (when) and lastly we get a result (then). This quickly snaps us into a context where there is a before and after. It also helps us realise that there can most likely be several other befores and afters. And now we have a format to capture this too.

It also allows us to write such specifications in the domain language. The whole idea behind Gherkin is that it should be written in a way that everyone who is affected by the software can read it. Here everyone includes everyone from end user to developer and operations people. Expressing our self in plain language using domain centric words allows us to have a dialogue with everyone involved where we can talk not just about how the world behaves but also about how we describe it. This is just as important as how it behaves. If we don't have words for something, or have different words for the same thing, we can't pinpoint it. We can't understand each other. Software, being executable writing (executable fiction even) makes it rather important that we can agree on what we call things and how we understand them within the given context.

Lastly, the specification we write can be made executable. Using Cucumber, or any other Gherkin execution library, we can create an automated test suite from the specification. Using the right reporting tools we can make this executed specification show up where it makes the most difference. On a dashboard, on our website or somewhere else. We can see clearly the state of our software. Information radiators of this kind are very valuable and helps the organisation build trust, both within and without.

To get you started with Gherkin check out cucmber.io's Docs.