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):
That statement went to Twitter, and I got reasonable question:
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:
SCENE I. Elsinore. A platform before the castle.
FRANCISCO at his post. Enter to him BERNARDO
Nay, answer me: stand, and unfold yourself.
Long live the king!
You come most carefully upon your hour.
'Tis now struck twelve; get thee to bed, Francisco.
For this relief much thanks: 'tis bitter cold,
And I am sick at heart.
Have you had quiet guard?
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.