🔥 Migrate Airtable to PostgreSQL in a few seconds 🔥
By
Daniel Martin
.png)
As the term signifies, behavior of the developed software drives the behavior-driven development (BDD) approach. This methodology is based on customers' expectations and perspectives. Daniel North pioneered the concept of behavior-driven development. His article on this subject published in 2006 soon gained popularity, and since then, the BDD approach has been widely adopted by a lot of software development companies.
Behavior-driven development describes the set of behaviors that the user can expect from the software, and this methodology is generally applied by product managers and business analysts. Since it is written in plain English, even the people without any technical knowledge can read and understand the expected software behavior. It bridges the gap between developers, testers, domain experts, and non-techies.
Below, we’ll explain the basics of behavior-driven development, and provide you with the examples, scenarios, and the most common and useful BDD tools with their descriptions.
BDD tools are not testing tools – they help you get a common understanding of how your software should behave. It’s mainly applied in the use case scenarios where the business team has a strong reason to assess the system behavior. It can be synced with integration tests, end-to-end tests, etc. You can integrate the BDD approach into the various scenarios, including the one when you build a web app or a mobile app using a low-code development platform.
A normal iterative BDD process starts with a User story, and includes 3 steps:
To better understand how BDD methodology works, let’s see the example. Below is a simple behavioral scenario for an ATM written in plain English, using Gherkin syntax, and having the Given-When-Then structure.
Given the account balance is 100 Dollars
And the ATM contains the cash
When the Account holder requests 20 Dollars
Then the ATM should dispense 20 Dollars
And the account balance should reflect 80 Dollars
In the Cucumber tool, you write these tests in Gherkin so that even non-tech-savvy individuals could understand them. When your developers get the tests, they can import the test scenarios into their development tool, and then automate the scenario steps accordingly. Once the flow is stabilized, they can regularly include these scenarios into the automated tests.
The scenario includes 3 sections – Context, Events, Outcome.
If a behavior functions appropriately according to the BDD scenario, the feature is marked as working. Every feature is associated with a feature file, and the set of behaviors is termed as a contract.
Behavior-driven development encourages the collaboration between business analysts, developers, QA engineers, and domain experts. Due to the constant cooperation, they share the overall understanding of the business requirements taking into account the customer’s perspective as well.
We can also define behavior-driven development as a set of practices that helps you enable your teams to deliver the software iteratively and incrementally. This set of practices includes Discovery, Formulation, Automation. They can be integrated with any of the agile methodologies like Scrum, Safe, etc.
Several development and automation test tools can be integrated with behavior-driven development tools. As a rule, developers and testers formulate BDD scenarios based on a discovery phase and the results of the collaboration with business analysts, an Ops team, etc.
Test automation developers implement test automation before the implementation of the code in production. Generally, the steps are the following:
For example, you have a feature with the context: “Given the car has started”. Then, when generating the step definition, you’d see the associated code as per the programming language in the development tool:
Given ("The car has started", function ())
{
// Code here
}
The function is run when the scenario is triggered.
When a QA engineer generates the step definitions, he's associating them with the script code for these scenarios written in Java, VBScript, Javascript, Python, C++ Script, C# Script.
Most popular BDD tools like Cucumber can be easily integrated with the development tools the dev team uses. For example, Eclipse IDE, TestProject, etc. allow for integration to BDD tools. Let’s briefly cover the most popular BDD alternatives and review their key features.
This tool has a free Open Source version – Cucumber Open, and the paid version – Cucumber Pro. This version offers you CucumberStudio and Cucumber for Jira. With Cucumber Open, executable specs are validated against your code. CucumberStudio simplifies the collaboration between the teams. They even offer the Cucumber School, which provides tutorials to help learn more about the tool. It supports several programming languages including .NET, Python, Java. According to the research, the Cucumber tool is much more widely used than other BDD tools.
Free and Open Source SpecFlow utilizes .NET and C# methods. Visual Studio allows you to build the feature files & the automation code. You can use the Gherkin editor at the formulation phase when writing the feature files, downloading them, and sharing. SpecFlow+ Runner is used at the automation phase as a test runner boosting the automation productivity. SpecFlow+ LivingDoc helps you generate living docs and reports, and share them with your team. SpecMap serves as a story map extension for Azure DevOps, and allows for integrating with Azure Boards.
This is an Open Source behavior-driven development framework created by Daniel North who conceptualized BDD. This BDD tool consists of two components – Jbehave Web and Jbehave Main. JBehave can be integrated with Selenium to run test scripts. It has IDE support (Eclipse, Netbeans). There’s an ability to generate reports in XML or HTML formats, or as a Text file.
Concordion is one of the most powerful BDD testing tools for writing acceptance test automation scripts. It supports Java IDEs like Eclipse and Netbeans. Concordion also supports Excel, which allows you to write the specifications in the spreadsheets. Thanks to the reporting feature this BDD software has, you can generate nice-looking reports.
FitNesse is an Open Source behavior-driven development tool developed by Ward Cunningham. It helps you to automate an acceptance testing process. Being written in Java, FitNesse exists as an executable JAR file including such elements as a web server, testing engines, etc.
TestLeft is a BDD testing tool that allows you to greatly speed up your testing process. With this BDD software, you have no need to program descriptions for every UI object manually due to the in-built UI Object Spy. TestLeft integrates with such BDD software as Cucumber, SpecFlow, JBehave, and supports .NET, C#, Java, and more.
It can be tough to implement behavior-driven development without enough collaboration between business analysts, developers, QA engineers, the Ops team, etc. This way of working aligns perfectly with a DevOps or a DevSecOps approach. Thus, all the team members are encouraged to be constantly in sync. When opting for a siloed working approach, you’ll hardly succeed with BDD.
If you choose to adhere to behavior-driven development, make sure that your team starts collaborating from the discovery phase (yes, developers and QA engineers are involved in the discovery phase). BA, Dev, and QA teams interact with each other while collecting the requirements and defining the specifications. Constant communication and quick feedback are vital in the BDD process.
When following the behavior-driven development methodology, you combine both business and technical aspects. BDD is not a simple testing activity – it’s a technique for designing & developing your software. It has also proven to enhance test automation in many ways.
Need an admin panel, a sales dashboard, an inventory management app, or another internal tool? Watch a demo – and get a full-value training and onboarding from the UI Bakery team. We'll help you build the first version of your internal tool – it's several times easier and faster with UI Bakery than with hand-coding.
