In the last post by Saket on DevOps and Test Automation, we got to know the different concepts and tools being used in DevOps. In continuation to that, I am going to focus on one specific tool i.e Cucumber. In recent past, I have worked a lot with Cucumber and have started to love the way it simplifies testing and makes life easy for QA and Development teams as well. We are planning to kick off a series on using Cucumber. But before we start with Cucumber, it is important to understand the Behavior Driven Development (BDD) approach. Lets discuss more about what is BDD, how it come in picture and what benefits it give over the traditional automation.
BDD is based on Test Driven Development(TDD) with an aim to bridge gap between business analysts and developers. There is lot already written on BDD, here is a link on BDD by the father of BDD himself – Dan North. I have embedded a youtube video by New Circle Training at the end of this post.
Behaviour –driven development is about implementing an application by describing its behaviour from the prespective of its stakeholders” – Dan North
The major misconception that people have is that BDD is a tool, Its a language specification and its not a tool. Before we go into more details let’s find how it comes into picture.
The overall concept of BDD was coined in 2009 by Dan North while giving a session on TDD in which he found some technical glitches in TDD approach. He overcome those glitches by writing first BDD framework in Java called JBehave. Later he wrote similar frame in Ruby which was called RBehave.
The main highlight of BDD is writing scenarios in plain English. This helps to effectively reduce gaps between Stakeholders,Business Analyst,Developer and QA.
To understand it more clearly ,lets look at the example below
|Feature: Refund item|
|Scenario: Jeff returns a faulty computer|
|Given Jeff has bought a computer for $900|
|And he has a receipt|
|When he returns the computer|
|Then Jeff should be refunded $900|
If you read the above scenario it is about returning of the faulty computer that Jeff has brought. The blue color text in the above example refers to some keywords. We will discuss in more details about it later in our upcoming articles on Gherkin. Subscribe to get notified.
So, to understand above scenario the person need not to be automation expert or functional expert.He/She can get an idea of the type of feature this scenario will test. With this advantage, many companies has started adopting BDD and it’s getting popular among test automation engineer. Their are various automation tools to support it .Some of famous automation tools are :
All of the above tools are used in conjunction with many different platforms and languages like Java,C#,Ruby,Python etc. All of these has one language in common i.e Gherkin. Now lets see what benefits it give over traditional automation.
|Its plain text and easily understandable||Its full of code and hard to understand.|
|Its easy to understand by BA/Dev/QA/Automation test engineer and all are on same page||Automation expertise required to understand the code|
|As scenario written in plain text we can share those with stakeholders||Impossible|
In next article we will start with the concepts of Gherkin.
Till then … Happy learning!!!