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):
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:
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.
