nonstopio
Published in

nonstopio

Selenium with Cucumber (BDD Framework)

Selenium Webdriver

Hello Readers,

Today, we are going to talk about Selenium BDD Framework. We have already talked about selenium architecture, reporting, etc. in previous blogs. There are many framework designs available today for making a test suite and we can implement them as per your requirement.

What is Cucumber?

Cucumber is a testing approach that supports Behavior Driven Development (BDD). It explains the behavior of the application in a simple English text using Gherkin language. Originally written in the Ruby programming language, Cucumber now supports a variety of different programming languages, including Java and JavaScript. The Cucumber framework is commonly used for acceptance tests.

Why Cucumber is more special

Most organizations use Selenium for functional testing. These organizations which are using Selenium, want to integrate Selenium with Cucumber as Cucumber makes it easy to read and understand the application flow.

The cucumber tool is based on the Behavior Driven Development framework that acts as the bridge between the following people:

  1. Software Engineer and Business Analyst.
  2. Manual Tester and Automation Tester.
  3. Manual Tester and Developers.

With the help of the BDD framework, we can improve our understanding of test cases and their use in the project.

Prerequisite for using Cucumber with Selenium

  • Selenium jar files:
  • Selenium-server-standalone

Please add the dependency of the below architecture in the BDD framework.

  • Cucumber-core
  • Cucumber-Html
  • cobertura code coverage
  • Cucumber-java
  • Cucumber-JUnit
  • Cucumber-jvm-deps
  • Cucumber-reporting
  • Hamcrest-core
  • Gherkin
  • Junit/TestNG

TestCase Scenerio

Below lines are written in the ‘MyTest.feature’ file using the Gherkin language as shown below:

Feature: Reset functionality on login page of Application 
Scenario: Verification of Reset button
Given Open the Firefox and launch the application
When Enter the Username and Password
Then Reset the credential

Code Explanation

Line 1) In this line we write business functionality.

Line 2) In this line we write a scenario to test.

Line 3) In this line we define the precondition.

Line 4) In this line we define the action we need to perform.

Line 4) In this line we define the expected outcome or result.

Step 5) Writing selenium test runner script for Selenium Cucumber framework design.

Now here we create the ‘StepDefinition’ package and then the ‘Steps.java’ script file under it. Here we actually write a selenium script to carry out the test under Cucumber methods.

package StepDefinition;		import cucumber.api.java.en.Given;		
import cucumber.api.java.en.Then;
import cucumber.api.java.en.When;
public class Steps {
@Given("^Open the Firefox and launch the application$")
public void open_the_Firefox_and_launch_the_application() throws Throwable
{
System.out.println("This Step open the Firefox and launch the application.");
}
@When("^Enter the Username and Password$")
public void enter_the_Username_and_Password() throws Throwable
{
System.out.println("This step enter the Username and Password on the login page.");
}
@Then("^Reset the credential$")
public void Reset_the_credential() throws Throwable
{
System.out.println("This step click on the Reset button.");
}
}

In the above code, the class is created with the name ‘Steps.’ Cucumber annotation is used to map with the feature file. Each annotation method is defined:

@Given annotation defines a method to open firefox and launch the application

@When annotation defines a method to enter the username and password

@Then annotation defines a method to reset the credential.

Under each method, we are only printing a message.

Advantages and Disadvantages of Cucumber

Collaboration
BDD encourages collaboration between business users, developers, and testers. These ‘three amigos’ come together to formulate an idea of the specifications and behavior of the application/product that they can all agree on. Traditionally, this collaboration takes the form of separate meetings: the business user talks to the developer; the developer talks to the tester; the tester talks to the business user. BDD stipulates that all parties should meet together to ensure that they are all on the same page.

Domain-Specific Language
BDD encourages the formalization and usage of a Domain-Specific Language (DSL) that encompasses the terms peculiar to the domain of your business and, therefore, is useful for defining the project specifications with greater precision. This helps to improve communication, drive consistency in specifications and avoid misunderstandings. Having a clear DSL that is used by all team members contributes significantly towards fostering understanding.

Automated Test Stability
When more thought is put into the specifications as the start, the automated test is likely to be much more stable. Of course, if the end-user keeps changing their mind about what they want, it will be difficult to keep the automated tests in sync with what’s being developed. In general, though, the more stable the specifications, design, and code, the easier it is to keep the automated tests running reliably. BDD encourages well-defined specifications and stable design from the start and, therefore, more stable automated tests as well.

Retrofitting can be time-consuming
Retrospectively fitting BDD to an existing project can be a time-consuming and difficult process. Should you invest in creating BDD feature files and scenarios for legacy features, or should you just focus on what’s coming next? This would be an important consideration with any specification and testing approach so, while not a drawback related specifically to BDD, it’s worth keeping in mind.

Documentation requirements
BDD does not mean you can do away with swathes of documentation. Just because you’ve created the user stories and described the behaviour of the application doesn’t mean you won’t need design documents or detailed lower-level specification documents. In many complex projects you may well decide that you need all the traditional types of documents as well. In this case, adding BDD documents feels like just another layer of documentation despite all the benefits.

Conclusion

In this article, we’ve tried to present as many characteristics and implications for and against implementing BDD as possible. While there are many success stories of teams that have implemented BDD, there are also many teams that have failed with BDD. More common, though, is that teams succeed and see the benefits, to begin with, only to give up after several months. There are many ways to avoid this, but one important way is to understand the issues you’re likely to encounter before you encounter them.

There can be many obstacles on the road when implementing any framework. If you think you can overcome that obstacle, don’t give up.

Thank you.

Happy Testing.

--

--

--

A Bespoke Engineering Studio

Recommended from Medium

Terraform: 10 tips to retain your sanity

What alerts should you have for serverless applications?

Searching for a Better Cloud DB Managed Service

Threads in Java:

Building a serverless website with S3

10 free stock photos you would actually use (Wednesday 18th 08AM edition)

Codeless Java Application Monitoring using Azure Monitor Application Insights

Announcing the Encode x Tezos Hackathon

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kishor Munot

Kishor Munot

Test Engineer

More from Medium

What is a Bug Bash?

Selenium vs Cypress — Which Is Better

Run Selenium tests in parallel with singletone Driver

Code-less Performance Automation Testing: Browser Level Performance Testing — A thought