Behavior-Driven Development (BDD) & Cucumber

Behaviour-Driven Development (BDD) is the software development process that Cucumber was built to support.

Behavior-Driven Development (BDD) & Cucumber

What is BDD?

We observe usually, product owners deliver their requirements to the developers as a first step during a development cycle, preferably before QA. As the development cycle begins, developers, product owners, stakeholders have a continuous communication, taking reference of the user stories and acceptance criterias. During the development process, product managers and stakeholders track the development progresses but sometimes technical side comes meaningless for them. At this point, a common language is needed like a bridge to connect stakeholders and technical teams. Behaviour Driven Development is a development approach which fills the information gap between stakeholders and development teams.

BDD ensures everyone (technical or not) has thorough visibility into the project’s progress.


On the other hand the nature of BDD can make separate requirement analyses (acceptance criterias) absolute, favoring product owners, business analysts and developers to work on same reference analyses source.

Optionally, business analyst can make ‘git commit’ on those source files.

Behaviour Driven Development is an extension of test-driven development

As developers target is to make pre-developed unit tests passes in TDD approach, similarly in BDD, developers target is to make behaviour-driven tests passes which are pre-developed usually by QAs .




Behaviour Driven Development uses examples to illustrate behaviour

The following is the Gherkin Syntax under Cucumber where you can practice BDD:

Scenario: Refund A Toy and Verify Refund Amount 
  Given a customer has purchased a toy
  And the toy cost 25$
  When the customer refund the toy
  Then the customer should be refunded 25$

In principle, aim is the answer the questions “WHO”, “WHAT”, “WHY”:



Describe the behaviour of your software in a very understandable way!
  • Given a context
  • When an event happens
  • Then an outcome should occur

Feature: Login functionality check
  As a customer manager
  I want to test login feature
  To verify whether customers can log in or not to the web application

  Scenario: Login with invalid email and valid password
    Given visit homepage
    When fill "Email" with ""
    And fill "Password" with "1313rpe2"
    And click "Login" button
    Then page should contain "Wrong email or password" content

As a result, considering the experimental approach in DevOps, BDD is worth the try by not ignoring the continuous improvement cycle, evolving it towards your internal dynamics.


Burak Koyuncu

Experienced Software Test Consultant with a demonstrated history of working in the finance and e-commerce industry.