Scribd
Upload
7 views

BDD

Behavior Driven Development (BDD) bridges the gap between technical and non-technical teams by using plain English (Gherkin) to describe project features, with tools like Cucumber facilitating this approach. BDD differs from Test Driven Development (TDD) by focusing on application behavior rather than implementation, and it encourages participation from all team members. Key components of BDD include feature files, step definitions, tags for running specific tests, hooks for setup and teardown, and backgrounds for common steps across scenarios.

Uploaded by

gitmaster52
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
7 views

BDD

Behavior Driven Development (BDD) bridges the gap between technical and non-technical teams by using plain English (Gherkin) to describe project features, with tools like Cucumber facilitating this approach. BDD differs from Test Driven Development (TDD) by focusing on application behavior rather than implementation, and it encourages participation from all team members. Key components of BDD include feature files, step definitions, tags for running specific tests, hooks for setup and teardown, and backgrounds for common steps across scenarios.

Uploaded by

gitmaster52
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

BDD (Behavior Driven Development):

 To fill the gap between technical team and non-technical team BDD came into picture.

 BDD uses simple plain English language (Gherkin) to the features, so that a non-
technical guy also understands the project flow easily.

 Cucumber is the tool one way to achieve the BDD approach. Another one is Spec flow

Required Dependencies:
 Cucumber Java
 Cucumber JUnit
 JUnit
 Selenium Java
 WebDriverManager
 Cucumber Eclipse Plugin from Eclipse Market

What is the difference TDD and BDD?

TDD (Test Driven Development) BDD(Behavior Driven Development)

 It mainly focuses on Implementation It mainly focus on behavior of the


of the Application. Application.
 It uses programming languages like It uses plain English language (Gherkin)
java/python to write the scripts. to write the features

 Participation: Technical team interaction more. All the team members including Client.

Cucumber Annotations:
 Given (): Pre condition.
 When (): Action
 Then (): Expected Results.
 And (): to extend

Feature file: Which allow us to write all the scenarios in plain English language (Gherkin).
Stepdefination-file (or) Glue Code: Which allows us to add all technical implementation of
feature file.
Runner Class: Where we can run our project or Run individual classes and It has different
options like.
@RunWith (Cucumber. Class)
@CucumberOptions (features= “./Features/Login.feature”,
glue = "stepDefinations",
monochrome=true, //to clean up the unwanted symbols in the console
dry Run=false, // will be used to check for any compilation errors and it works like a headless
browser testing
plugin= {"pretty","html:reports/cucumber.html"}
)
public class RunnerClass {
}

By using Examples: we can do Parameterizations in BDD(Cucumber) when we need to execute


same scenario with multiple set of data.
Examples:

| username | password |
|[email protected] | admin@123 |
|[email protected] | admin123@ |

changes to be made in feature file at passing values.


When User enters valid <username> and <password>

Changes to be made in stepDefination or Glue code is at method.


@When ("^User enters valid (. *) and (. *)$")
public void userentervalidUsernameandPassword (String username, String password)
{
driver. findElement (By.id("email")). sendKeys(username);
driver. findElement (By.id("passwd")). sendKeys(password);
}

TAGS:
It will be used when we want to run different test cases from scenarios like
@SmokeTest, @SanityTest @RegressionTest etc...

Changes to be made in Feature file:


@smoke
Scenario1
Given
When
Then

@sanity
Scenario2
Given
When
Then

@regression
Scenario3
Given
When
Then

Changes to be made in RunnerClass are.

@RunWith (Cucumber. Class)


@CucumberOptions (features= “. /src/test/resources/features”,
glue= {"stepDefinationsGluecode"},
monochrome=true, //to clean up the unwanted symbols in the console
dry Run= false, // will be used to check for any compilation errors
plugin= {"pretty”, html: reports/HtmlReports"})
tags="@smoke" //tags="@sanity" //tags= {"@smoke" or @sanity or @regression}
//tags {"@smoke" and @sanity and @regression}
public class RunnerClass {
}

HOOKS:
Hooks are listeners in TestNG
To manage setup and tearDown methods we use @Before and @After hooks

Code reusability is the advantage of HOOKS.


@BeforeStep and @AfterStep will execute before and after every step in stepdefination.
Example: If I use @BeforeStep and @AfterStep

@BeforeStep
public void setup ()
{
Syso ("I will execute before every step")
}

@AfterStep
public void after ()
{
Syso ("I will execute after every step")
}

@Given ("User is at index page")


public void userisatindexpage () throws Exception {
openBrowser ();

@When ("UserclickonSignInoption")
public void UserclickonSignInoption () {
loginpage = new LoginPage ();
loginpage. signInOption ();
}

output:
I will execute before every step
@Given
I will execute before after step
I will execute before every step
@When
I will execute after every step

But @Before and @After hooks executes only before and after scenarios.
Conditional Hooks: If I want to execute some of the methods in order.

@Before(order=0)
public void setup ()
{
Syso ("I will execute first")
}

@Before(order=1)
public void setupOne ()
{
Syso ("I will execute second")
}

@After(order=0)
public void after ()
{
Syso ("I will execute second")
}

@After(order=1)
public void afterOne ()
{
Syso ("I will execute first")
}

BACKGROUND: A Step or Group of steps common to all the features (Example: Login is common
for some functionalities hence make login as background)

Backgrounds will be defined in Feature file and runs before every scenario. Unlike hooks
background visible to users.

When to use: When there are common steps in Feature file.


Example:

Background: User login functionality


Given User at index page and clicks on SignIn option
When User enter valid username and password
And User click on Login button
Then User navigates to Dashboard
Scenario: Adding Product to the cart
Given User logged in
When User is searching for a product
And User trying to add that product to the cart
Then User added the product successfully

Scenario: User edits his profile details


Given User logged in
When User click on Profile
And User navigates to Profile page
Then User edits username in the Profile page

You might also like