Introduction to Behaviour Driven framework…

Cucumber is one of the most widely used BDD (Behaviour Driven Development) tools. Before diving deep into a BDD tool, let us first discuss on TDD and BDD approach.

TDD or Test Driven Development approach is actually converting Software requirements into automated test cases. It’s generally described as writing a failing test case first and then make the test pass and then refactor. In other words, throughout the development cycle, the test cases are run over and over again, thus improving the software as test cases pass. This is more of a  developer oriented approach.

BDD or Behaviour Driven Development approach is actually defining the user behavior first, before writing automated test scripts. User behavior is defined after a collaborative discussion by QA, Developers, and Business. Once the behavior is finalized, test cases are written in a plain English language using ‘Given’, ‘When’, ‘Then’, ‘And’ keywords. Developers start writing the functional code only after user behavior is defined. This actually reduces the risk of developing codes that deviates from accepted user behavior.

There are many tools similar to Cucumber, such as Jbehave, Nbehave, specflow, JDave etc. However, Cucumber is widely used because it is simple and easy to use. Also, the default reports for Cucumber looks good and with Jenkins/Bamboo plugins, it can generate good-looking reports.

In this post, we will mainly focus on creating a BDD framework using Cucumber. Our new framework will have all existing features from our old Hybrid Framework which actually follows a TDD approach.

Before we move into development, let us first focus more on the framework details:

  1. This framework will be developed in Eclipse using Maven. The pom.xml will almost be same as mentioned in Hybrid Framework, however, we will have to add Cucumber dependencies like Cucumber-core, Cucumber-java, Cucumber-java-deps, Cucumber-jvm etc..
  2. We will use Gherkins language for defining user behaviors which are nothing but .feature files. Cucumber understands and executes these .feature files. A .feature file will at least contain a Feature name,  Scenario and executable statements having keywords like ‘Given’, ‘When’, ‘Then’, ‘And’. Note that a Feature can have multiple scenarios in it.
  3. Gherkin itself is very simple, readable plain English text with a little extra structure. To learn more about Gherkin syntaxes, visit cucumber.io website.
  4. Once the user behavior is defined using Gherkins language, our next task will be to create step definitions. A step definition is a Java method with an annotation above it. The annotation is followed by a pattern which is used to link the Java code to a particular Gherkin step. We will be able to follow more as we proceed with framework development.
  5. Cucumber will create its own reports, however, we will also use Extent reports in our framework.
  6.  New Tours Demo will be our demo application.

 

This is just an introduction to what we are going to develop in our next post. I am quite sure that it’s going to be an interesting one. Keep following, till then, Happy Reading!