I constructevly object to Gherkin language

Reading Time: 2 minutes

TL;DR

In this post, I give constructive example why using Gherkin as communication tool  is not productive. At CAST 2016, I gave 5 minute lightning talk “I constructively object to UI automation. This first part is about using Gherkin language as communication tool.

I sad in lighting talk (thanks Neil):

Screen Shot 2016-08-31 at 10.32.22 PM

That statement went to Twitter, and I got reasonable question:

Screen Shot 2016-08-31 at 10.32.34 PM

I consider “pretty sloppy” remark as “highly creative”.

I am giving example why I think that Gherkin language is bad for communication. And I welcome you to prove me wrong.

It is important to state that James Bach already have spoken his mind about this topic: Behavior-Driven Development vs. Testing

So here is example. Let’s write start of Shakespeare Hamlet in Gherkin:

Feature: ACT I SCENE I. Elsinore. A platform before the castle.

Scenario: FRANCISCO at his post meets BERNARDO

Given that Francisco is at his post

When Bernardo approaches in dark

Then Francisco asks who is there

Scenario: Bernardo replaces Francisco at his post

Given that is midnight

When Bernardo offers to replace Francisco at his post

Then Francisco accepts this greatfully

Scenario: Type of guard

Given that Francisco had quiet guard

When Bernardo asks him about his guard

Then Bernardo confirms that he had quiet guard.

And here is original play:

ACT I

SCENE I. Elsinore. A platform before the castle.

FRANCISCO at his post. Enter to him BERNARDO
BERNARDO
Who's there?
FRANCISCO
Nay, answer me: stand, and unfold yourself.
BERNARDO
Long live the king!
FRANCISCO
Bernardo?
BERNARDO
He.
FRANCISCO
You come most carefully upon your hour.
BERNARDO
'Tis now struck twelve; get thee to bed, Francisco.
FRANCISCO
For this relief much thanks: 'tis bitter cold,
And I am sick at heart.
BERNARDO
Have you had quiet guard?
FRANCISCO
Not a mouse stirring.

Notice the difference?

When we try to fit interesting user stories in Gherkin Given When Then format, we lose a lot of beautiful and important information. I read a lot of blog posts “How to effectively written scenarios in Gherkin format”.

For example: Describe every scenario in ONLY three steps, Given When Then !?

But scenario, not feature, is core of every application. They describe how application features, building blocks of scenario, are combined together to provide VALUE for the USER. This is how application will be used by REAL users. Do you really think that users think in Given When Then format?

This is like we have a hammer and we will make Eiffel tower with only hammer, here are the instructions.

Hamlet in gherkin is not a Hamlet. Why not read actual Hamlet in order to be able to test it?

Another point. Gherkin was introduced as communication tool. Gherkin is documentation communication tool.

So here is alternative that I propose. As I am testing various projects, for me the best sources of communication are:

  • application under test
  • tester that provides information about application and is happy to share it with others
  • developers that implemented that information into the application
  • git (github, bitbucket, gitlab) – to find out what changed in application

And when I communicate with them (or just listen their conversations or read slack chats) I always get UP TO DATE, LATEST information about application under test.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

5 thoughts on “I constructevly object to Gherkin language”

Leave a Reply

Your email address will not be published. Required fields are marked *