BDD (Behaviour-Driven Development) – Nuts & the Bolts

BDD (Behaviour-Driven Development) is an agile development technique which encourages collaboration between Business, Dev and QA. BDD first coined in 2009 by Dan North. It is an extensive approach of Test Driven Development, Acceptance Test-Driven Approach, and Domain Driven Design to snag down their drawbacks.

BDD came in to picture since requirements are often interpreted differently by teams. It leads loss of time in back and forth communication while refining the exact requirements. So as to save complexity in process BDD evolved and currently many organizations have adopted it.

BDD adopts three basic principles:

  • Enough is enough: The sufficient amount of time should be taken for planning, development, and testing.
  • Delivering value with quality: Shooting in the dark does not make sense as it hampers client, stakeholders, and users at the same time. So, proper analysis of requirements is a thumb up which BDD follows.
  • Behavior is the crux: Focuses more on behavior of product that will lead to better delivery and happy customers.

BDD (Behaviour-Driven Development) can be implemented using Gherkin language with BDD tool. Some of the widely used tools which BDD supports are Specflow in C#, Cucumber in Ruby, Freshen in PHP, and Jbehave is in Java.

A question may arise in your mind what is Gherkin? Everything needs a representation so does BDD, hence a form of representation Gherkin is introduced which is easy to understand domain-specific language or simply layman’s language. It defines the structure and syntax of the tests. Moreover, it also supports over 40 languages which boost documentation as well as test cases.

Gherkin Source file format has ‘.feature’ the extension which is commonly known as Feature file. Feature file is so simple which everybody across the board (developer, tester, BA and business) can understand. This feature file contains a list of independent scenarios, written using keywords like Given, When, Then etc. Mapping of requirement with scenarios is done using Feature file.

Now, the next step is binding these readable specifications to machine language which is achieved by using any BDD tool Specflow, Cucumber, etc. These tools convert human readable format into machine code.

How BDD works?

BA/ SME create Feature files in domain specific language then Feature and Scenarios are agreed by Dev, BA and QAE teams. Dev develops code for the same scenarios and QA creates BDD tests using tools and framework. These tests are run as a part of Continuous Integration for every build and finally, it is shared with the entire Sprint team.

Implementation of BDD using Specflow

As described above User Story are the requirements that are tied together. The User story is a scenario where an object performs an activity and end results or state of the activity are validated and tested later.

Once client or stakeholders are done with the requirements, it is converted into Feature files using Gherkin. Feature file is the entry point of the tests which works as the script as well as document. It may contain a scenario or a list of scenarios.

Gherkin has below-mentioned components that are used while writing the executable Scenarios:

  • Feature
  • Scenario
  • Given
  • When, And, Then, but
  • Scenario Outline
  • Examples

Later these Scenarios as converted into Step Definition using Specflow and Selenium. Every line in Feature file transforms into methods and code can be developed using Selenium and C# (depending on what BDD tool is being used). All together when enough Scenarios are covered, it is considered as deployed for all the Sprint teams.

Along with these positive aspects, BDD (Behaviour-Driven Development) holds some downside too. The primary downside is if any requirement is the unclear and User/Client not available to discuss then it becomes difficult to work with unclear feature. Also, clarification among teams consumes a lot of time every so often. On the first side BDD nails down all the leaps in the dark ensuring more successive approach, leveraging it many firms are boosting their client list and projects.

Testing in Agile with Behavior Driven Development


In today’s hyper-competitive business environment, organizations are constantly innovating to gain an edge in the market. Towards this objective, most organizations have adopted Agile and DevOps practices for delivering software. A common practice that has evolved much over the last two decades is automation of testing. Various tools and frameworks have evolved in these two decades with an intent to reduce the cost of automation as well as to popularize its use across various persona in the SDLC for enabling better collaboration and effectiveness.
One of the key challenges of test automation remained a lack of common understanding between the business analyst, manual tester, developer and automation engineer of what was being tested and how. Behavior Driven Development was introduced to bridge this gap and bring the domain expertise, business logic, and tests into a common framework comprising of a language based inputs and popular test automation tools.

Behavior Driven Development (BDD) Explained

BDD (Behavior Driven Development) style framework makes use of simple, domain-specific scripting language (DSL). These domain-specific scripting languages convert structured natural language statements into executable tests. The outcome is a closer relationship to the acceptance criteria for a given function and the tests are used to validate that functionality.
high-level structure of the implementation
BDD primarily works with open source tools and technologies like Selenium WebDriver, Appium and other Java-based libraries for test implementation and support. In this approach, Gherkin language is a layer of abstraction which works on an implementation layer which in turn is integrated with the execution layer. Figure 1 depicts the high-level structure of the implementation.

Test scripts developed in BDD framework provides a clear picture of the behavior/flow of the system and applications under test, the input and its expected output.
BDD also supports various types of test data management approaches. The test data can be managed in the feature file with scenario outline and example as well as externally using various forms like JSON, XML, Excel, etc.

BDD Tools

BDD act as a test layer that can be easily integrated with any type of automation framework. Some of the popular tools like Cucumber provide support for both pre-defined steps and customized steps which can be directly used by the testers for scripting. The different BDD implementation tools available in the market support various types of programming languages like Java, C#, Ruby, Python, etc. which increases the potential of framework customization and adaptability.

Selecting a BDD tool:

Every tool and approach have its pros and cons. Careful consideration has to be given in selecting the right tools in order to be successful. Before making any decision on the BDD approach implementation it is always advisable to understand the application flows, features, behavior and the kind of testing that needs to be performed. There should be a thorough research on the fitment of BDD with the framework along with a proper design which makes the BDD implementation more successful.
In order to reap the maximum benefits of a tool or an approach, it is always advisable to follow its best practices.
Caution: BDD may not be the ideal framework in every situation. E.g. in case of scenarios comprising of the very large number of test steps, BDD framework could result in increased test script maintenance. It is always advisable to externalize the test data from the test scripts and the code implementation. Hence the feature file’s test data management feature is not recommended if the test data is huge.
If you have an existing product and you want to automate a large set of regression tests, (re)writing these as feature files using Gherkin syntax and parsing them in your framework would not add much value as the feature is already developed.
If the test case scripting in BDD form is not carried out in a controlled or disciplined way, it might lead to certain problems like duplication of steps which would result in the unmanageable and confusing framework.

Common Features of BDD tools:

Some of the features of Cucumber (commonly used to implement BDD framework) are mentioned as below:

  1. Uses plain English user-friendly language to script.
  2. Open source and easy to understand and implement.
  3. Test data can be managed with feature files in case of small applications and externally for medium and high complex applications.
  4. Supports informative and detailed test execution reporting. There are options available to plug in various different reporting libraries like extent reports, cucumber enhanced reports, etc. with the BDD framework. These reports can be customized as per the requirement of the project.
  5. BDD framework can be easily integrated with Jenkins and other related tools in order to support Continuous Integration and delivery models.
  6. BDD framework implemented using these tools can be easily integrated with 3rdparty tools to support Test Management and Defect Management processes.
  7. BDD style frameworks are supported for all the platforms and applications like Desktop/Mobile Web and Mobile Apps.
  8. Parallel execution, headless browser execution, API based execution are all achievable with BDD. There are a lot of open source tools available in the market supporting these concepts or integrations. To name few of them, Selenium and Appium grids with Cucumber to support parallel execution, Rest Assured to support API based executions, etc.
  9. BDD framework also supports Cloud-based execution with various providers like AWS, SauceLabs, Xamarin, etc.

Best practices for implementing BDD

  • If the automation framework provides pre-defined steps to use, then there should be the proper availability of cheat sheet/document to refer otherwise it would really become a bottleneck for testers to script with the BDD style framework.
  • Actions/methods developed for the steps definitions should be reusable and mapped to unique actions or activities.
  • Features provided by BDD like Background, Hooks should be wisely used.
  • Feature files created should be unique and be mapped to the application features.
  • The detailed narrative should be provided to understand the feature and its scenarios.
  • As mentioned above, test data should be managed externally in order to separate test data management, test cases management, and the framework code.
  • There are a lot of online tutorials available to understand the workflow of BDD and its implementation with the different types of automation frameworks and approaches.

The Benefits of BDD

  • BDD test cases are in the form of plain English language, thereby reducing the need and effort of maintaining additional documentation.
  • With BDD, testers can script test cases in parallel to development, which in turn saves a lot of efforts required later during automation scripting.
  • Another important benefit of BDD is that even a non-technical tester can develop and maintain automation scripts, thereby reducing dependency on technical members who in turn can dedicate their time to software development.
  • High visibility of project’s progress to all the stakeholders is ensured with BDD (HOW?).
  • Cost and effort of testing a product reduce considerably.
  • Requirement traceability matrix can be easily generated with this approach.
  • Finally, the software/ product gets delivered with high quality in a short period of time, providing business agility

At ImpactQA, we have recently implemented BDD for automation in several projects and customers are reaping the benefits listed above. For any questions or comments, please reach out to us at