With the previous blog we learnt to develop a POM based Selenium Automation Framework. Lets extend that framework and implement a Behavior Driven Development Cucumber Framework. Before getting started with the BDD Cucumber framework design, lets understand what BDD is.
BDD or Behavior Driven Development is an extension of test-driven development that makes use of a simple, domain-specific scripting language. These DSLs convert structured natural language statements into executable tests. Now these tests validate the functionality and compare it with the acceptance criteria of the functionality.
BDD forces automation framework to put emphasis on identifying business scenarios, determine the area to test the desired behavior and identify the scenarios to ensure the feature is well tested along with its clearly defined scenario steps.
There are 2 types of BDD framework.
- Cucumber: BDD with Cucumber uses Gherkin Language for developing the framework. It supports, Java and Ruby language.
- SpecFLow: BDD with SpecFlow also uses Gherkin Language for developing the framework but supports C# language for its code base.
In this blog we will be developing Behavior Driven Development Cucumber framework. As we have seen above that BDD framework with Cucumber uses Gherkin language. Lets try to understand what Gherkin language is:
It is a Business readable domain specific language(BRDSL). Gherkin is plain-text English with a little extra structure that describe software’s behavior without detailing how that behavior is implemented.
In Gherkin, each line has to start with a Gherkin keyword. The main keywords are:
- Steps: Given, When, Then, And, But
- Scenario Outline
A feature has three basic elements—the Feature keyword, a name and description. Cucumber does not care about the name or the description—the purpose is simply to provide a place where we can document important aspects of the feature, such as a brief explanation and a list of business rules (general acceptance criteria).
Given: The purpose of given is to put the system in a known state before the user (or external system) starts interacting with the system. Given used to be the preconditions whenever we will be creating the use cases.
When: When steps are used to describe an event, or an action. This can be a person interacting with the system, or it can be an event triggered by another system.
Then: Then steps are used to describe an expected outcome, or result.
And, But: These are used to show conjunction between two conditions.
There used to be situations where same Given steps gets repeated in all of the scenarios in a feature file. We can move such Given steps to the background by grouping them under a Background section before the first scenario:
- Scenario Outline:
When we have a complex business rule with several variable inputs or outputs, We can simplify it with a Scenario Outline.
A Scenario Outline section is always followed by one or more Examples sections, which are a container for a table. The table must have a header row corresponding to the variables in the Scenario Outline steps.
Before getting started with the BDD Framework design, we need few things as prerequisite of the framework.
1. Cucumber Eclipse Plugin:
- Go to Help—>Install New Software in Eclipse
- Enter this url: http://cucumber.github.com/cucumber-eclipse/update-site and install it.
2. Cucumber JVM for Eclipse:
Cucumber functionality is abstracted out in jars and following Cucumber jars/modules are required to run a Cucumber test with Java in Eclipse.
These can be downloaded from maven repository.
Now lets get started with the BDD Cucumber framework development.
Our framework structure will be similar to:
As this framework is an enhancement of the POM Selenium framework, the base structure would be similar.
1. Developing Base:
src.utils: This package will contain utilities related to driver and helper files that will be used throughout the framework. This structure will be same as discussed in the previous blog.
src.pages: This will contain the pages corresponding to ones present in the application. This structure would also be same as discussed in the previous blog.
2. Developing BDD structure:
We will be implementing BDD in following packages:
src.test.resources: This will include the feature files which contains a list of scenarios to be tested for that feature. We will be creating the feature file using Gherkin language discussed above.
Post_Ad.feature: This is the feature file created with extension .feature.
@smokeTest is a tag that is been used to group the tests. Rest of the things are Gherkin language where we have elaborated our scenario in a defined way.
src.test.java: This package will contain the step definition files. The steps we have added in the feature file are mapped to step definition. These step definitions are block of code which gets executed when the scenario runs. If any line of code inside the step definition returns an error or exception to the Cucumber Runner, then that step is marked as failed, otherwise pass.
The step definition has a defined structure that the statement will get started with a ^ and ends with a $. Now for each statement a method will be created that will be a group of executable statements.
If we see closely, these are the same statements mentioned in the feature file.
src.test: Now the question comes how these feature files are bind with the step definition files and how this will get executed.
As we are using Cucumber, there is a certain package structure that should be followed. So we are keeping the feature file in the src.test.resources package and step definition under src.test.java package. And in this package we will be having our testRunner file which will be used to execute the test.
First import statement ‘org.junit.runner.RunWith’ imports @RunWith annotation from the Junit class. @RunWith annotation tells JUnit that tests should run using Cucumber class present in ‘Cucumber.api.junit‘ package.
Second import statement ‘cucumber.api.CucumberOptions‘ imports the @CucumberOptions annotation. This annotation tells Cucumber a lot of things like where to look for feature files, what reporting system to use and some other things also.
This statement is been used to generate the report in defined folder structure.
3. Test Execution:
There are certain ways to execute the test.
We can execute all the test present or we can group our test as per the functionality and run a particular set of tests.
Some annotations like @smokeTest or @regressionTest can be used to group the tests. These annotations are called tags.
We need to mention the tag in the feature file so that the corresponding tests can get executed.
To execute the test, right click on TestRunner.java file and run as Junit.
We can have a html report located in the location mentioned in TestRunner.java file.
We also have a junit report.