The LEAP

Automation insights and productivity tips from LEAPWORK.

All Posts

Behavior-Driven Development (BDD) Introduction

In a traditional software development process, developers write programs and build features, and testers then test the written pieces of software. However, businesses are now operating at a faster pace and, therefore, software development needs to keep up with business demands.

In order to guarantee software quality at this development rhythm, the traditional software development process has shifted towards more Agile methodologies. One of these is Behavior-driven development (BDD).

What is Behavior Driven Development?

Behavior-driven development (BDD) is a methodology in Agile software development that aims to narrow the communication gaps between team members. In this method, the collaboration between developers, QA and non-technical or business analysts in a software project is encouraged. It encourages teams to use conversation and real-world examples to foster a better and shared understanding of how the application should behave. 

BBD ProcessThe Behavior Driven Development process

 

It emerged from test-driven development (TDD), where tests are written before code and passing the tests is the critical driver of software development. BDD makes use of the general techniques and principles of TDD while providing all relevant teams with a shared process to collaborate on software development.

This shared process is facilitated through the use of a simple domain-specific language (DSL) using normal language constructs, such as English-like sentences, that express the behavior and expected outcomes.

 

Behavior Driven Development and Test Automation

Behavior-driven development makes us rethink our approach towards unit testing and acceptance testing so that we avoid issues that naturally arise.

Unit tests should be specified in terms of the desired behavior of the unit, that is the requirements set by the business. By specifying these terms in advance, we make sure that developers won’t have to revisit work because requirements were misunderstood.

In BBD, unit test names are whole sentences starting with a conditional verb – “should” – written in order of business value. At the very beginning of a feature file, we write acceptance tests using the standard agile framework of a user story:

  • As a [role]
  • I want [feature]
  • So that [benefit]

Once the feature file has been established and agreed by the business participants, we then write the acceptance criteria to test that behavior. The acceptance criteria for a feature is written in terms of scenarios and implemented as classes. This allows for regular expressions – DSL – to map steps in a feature file to concrete actions. A scenario is written in the following format:

  • Given [initial context]
  • When [event occurs]
  • Then [ensure outcome]
  • And/But [more outcomes if applicable]

BBD allows for easy test automation. The suite of unit tests is continuously providing feedback to ensure that each key component is still working. The unit tests act as evergreen documentation so, in a way, the test suites also function as a regression safety net on bugs.

 

Key Takeaways

  • BDD is a collaborative method that requires a cross-functional team consisting of customer/client, BAs, QAs, testers, UI & UX designers and software developers.
  • It is an outside-in activity, meaning that the entity that has commissioned the software unit under construction ensures control over the “desired behavior”.
  • It uses domain-specific language (DSL) that can be easily read and understood by everyone.
  • Test cases clearly articulate what we need our code to do.
  • It forces critical analysis and design since the developer needs to fully understand the desired result product and how to test it before developing the production code. This, in turn, reduces the overhead caused by common developer hurdles.

By using BDD as a form of test automation, companies can streamline activities in software development. Whether you want to avoid technical time waste caused by a reluctance to refactor code, slow feedback caused by handovers and silos, or rework caused by vague requirements, BDD offers a pro-active approach to software development.

BDD is a way of working that applies in both development, as described in the above example above using unit testing, and also in QA. In this blog, you can read about how LEAPWORK can be used for QA in companies who have chosen to work with a behavior-driven development method.

Download BDD Whitepaper

Lucia Cavero-Baptista
Lucia Cavero-Baptista
Content Marketing Manager

Related Posts

Streamlining System Upgrades in ServiceNow with Automated Testing

For many enterprise businesses, ServiceNow is an operational backbone. But twice a year, panic unfolds. ServiceNow release two major mandatory upgrades requiring extensive testing. And more often than not, functional and regression testing gets postponed or left behind.  When these tests are postponed or skipped, it leaves businesses open to risk. In these key moments, system administrators and developers face pressure to complete functional and regression testing at speed.

Decoding Automation Podcast: #6 How No-code Test Automation Closes the Skills Gap in Software Development

Test automation is a key part of becoming agile for software development teams, yet code-based automation solutions act as a barrier to agility due to the time and resources they require to use. So how can teams implement automation that enhances their agility despite limited time and resources?

Codeless ServiceNow Automated Test Framework

Testing is a crucial part of ensuring the quality of your business-critical processes. For businesses using ServiceNow, the ServiceNow Automated Test Framework (ATF) is an obvious candidate. But it’s not necessarily the best solution for your team if you want to scale your testing efforts while keeping resource spending low.