+++
title = "Things I Learnt The Hard Way - Gherkin Is Your Friend to Understand Expectations"
date = 2019-06-19
[taxonomies]
tags = ["book", "things i learnt", "gherkin", "expectations"]
+++
Gherkin is file format for writing behaviour tests (BDD). But it can also give
you some insights on what you should do.
<!-- more -->
Alright, let's talk a bit about Gherkin:
[Gherkin ](https://en.wikipedia.org/wiki/Cucumber_(software )#Gherkin_language )
is a file format created for [Cucumber ](https://en.wikipedia.org/wiki/Cucumber_(software )),
which describes scenarios, what's in them, what actions the user/system will
do and what's expected after those actions, in a very high level, allowing
people without programming experience can describe what's expected from the
system.
Although Gherkin was born with Cucumber, it is now supported by a bunch of
programming languages, through external libraries.
A typical Gherkin file may look something like this:
* **Given that** _initial system environment_
* **When** _action performed by the user or some external system_
* **Then** _expected system environment_
Or, in a more concrete example:
* **Given that** The system is retrieving all tweets liked by the user
* **When** It finds a tweet with an attachment
* **Then** The attachment should be saved along the tweet text
Pretty simple, right?
Now, why I'm mentioning this?
Sometimes, specs are not the most clear source of information about what it is
expected from the system, and up can't think of [steps to do
so](/books/things-i-learnt/steps-as-comments). If you're confused about what
you should write, asking the person responsible for the request to write
something like Gherkin may give you some better insights about it.
Obviously, it won't be complete. People tend to forget the error situations --
like filling the name field with numbers, using characters in age fields,
tweets with no text and just attachments -- but at least with a Gherkin
description of the system, you can get a better picture of the whole.
Also, you may not like to write specs. That's alright, you can replace them
with Gherkin anyway.
{{ chapters(prev_chapter_link="/books/things-i-learnt/steps-as-comments", prev_chapter_title="Write Steps as Comments", next_chapter_link="/books/things-i-learnt/patterns-not-solutions", next_chapter_title="Design Patters Are Used to Name Solution, Not Find Them") }}