Behavior-driven development (BDD) addresses the problem of implementing poorly defined requirements by leveraging the domain expertise of business and QA professionals to ensure that the development team builds the correct software. Read on to learn more about how to adopt BDD in the enterprise.
Over the past several years, many organizations have transitioned to agile development in order to accelerate delivery and get more timely feedback from the market. In these organizations, while development begins to move faster, QA will struggle to keep pace unless they integrate automated software testing practices into the development pipeline, so that is often the first bottleneck to overcome.
But after successful adoption of test automation and the whole organization moving more quickly, organizations start to ask themselves if they are building the right software. Accelerating software development and ensuring software quality with automated continuous testing is a great achievement, but it’s all for naught if the software isn’t what your customers want or need.
Folks at this stage in their software development processes evolution are taking a close look at BDD as a means of ensuring that their software meets their organization’s business requirements. But what exactly is BDD and how does it pertain to testing?
TDD vs. BDD
BDD is an evolution of the test-driven development (TDD) methodology, in which developers write the test beforewriting the code. After crafting a failing test to start, developers practicing TDD write just enough code to ensure that the test passes, then write another test; rinse and repeat. The result is lean and mean code with high test coverage.
TDD is an activity designed to improve software quality and ensure code coverage. BDD, in contrast, solves the problem of correctly implementing requirements. Rather than focusing on the test to verify the functionality you want implement, BDD is about defining the behavior of the application so that it meets specific business requirements.
The similarity between TDD and BDD is that a contractual mechanism is implemented before any work is done, to ensure that the output matches a specific expectation. But this is where the similarity ends. In TDD, the test is a contract intended to ensure that the application meets a specific functional requirement. In BDD, the behavior is the contract intended to ensure that the application meets a specific business requirement.
What is BDD in Software Development?
We’ve been casually throwing around the term “behavior,” but it does have a technical meaning in the context of BDD. In BDD, behaviors are carefully-crafted, human-readable statements that follow a specific format. They are collected in “feature files” that can be integrated into the development process.
Feature files are typically written in Gherkin, which is a BDD-specific syntax that enables BDD tools, such as Cucumber and SpecFlow, to automate the process of validating the behaviors. These BDD tools parse the behaviors in the feature file and execute the appropriate “glue code.” This glue code maps “behaviors” to execution steps, typically Java or .NET test code written by a developer, in a specific test engine. These mappings are commonly referred to a ‘step definitions,’ or ‘step-defs.’ As a result, testers can use feature files as test cases that verify the behaviors associated with the requirements.
What are the Benefits of BDD?
There are several advantages that Business-Driven Development brings to software development. With BDD, you can:
- Increase collaboration. BDD provides a common language for the different roles in the organization. This helps technical and non-technical team members understand the intended functionality and business requirements of the project.
- Leverage a broader range of domain expertise. Because behaviors are defined in a human-understandable format, organizations can leverage the expertise of testers, architects, and other stakeholders who have different perspectives and backgrounds.
- Meet requirements with a strong focus on testing. BDD drives test coverage with a focus on meeting the requirements, which ensures that the end-product is pertinent to the business needs of an organization.
- Promote reuse and reduce the complexity of automation. Developers writing the glue code are encouraged to write reusable test steps, as well as more testable code. For example, an application may have some repetitive set-up steps that need to be invoked to achieve a certain state. A developer can define those steps in the glue code, which can be reused to handle set-up and execution.
This last point is one of the key features of BDD. Modular, reusable test steps enable testers to rely on the BDD tool to do the heavy lifting when verifying and validating the requirements. The sticking point, however, is that developers are still required to write the glue code that binds the behaviors to the requirements. We’ll talk more about this next.
Costs of Implementing BDD in the Enterprise
The biggest cost associated with implementing BDD is writing the glue code. In most cases, this task falls on the development team, which shifts the burden of creating the test artifacts for validating the requirements from testers to developers.
In a pre-BDD world, testers would use tools and frameworks to create tests that validate the functionality, not necessarily the requirements. With BDD, testers, business analysts, and other stakeholders define behaviors in a feature file, but developers or people with code-writing skills are still required to write the glue code that maps the behaviors to the functionality.
The fact that BDD adds to the cost of development can hurt organizations with limited development resources. Although the glue code is intended to be reusable and easier to leverage for test automation, the investment required to scale and implement BDD across the entire enterprise is often too high.
How to reduce the technical burden of BDD
Parasoft enables non-developers to write step-defs that execute as SOAtest tests, which greatly reduces the technical resources required to write tests. With the Parasoft SOAtest-Cucumber Executor, each step definition maps to a reusable SOAtest test or test suite that runs when that step is executed.
Consider the following examples:
- A step definition references a SOAtest REST Client that calls a specific API
- A second step definition references a SOAtest REST Client connected to a JSON Assertor that validates the data in a response from a different API
- A third step definition references a SOAtest DB Tool connected to a Value Assertor that executes a DB query and validates the data in the result set.
Step definitions can also reference an individual SOAtest test or a test suite that contains a number of tests within.
Parasoft puts more control in the hands of testers and gives them confidence that they’ve completely covered the functionality under test. Leveraging a mature, feature-packed, end-to-end testing solution provides easy entry into test automation, test maintenance, and a natural integration into existing CI/CD workflows. At a high level, it enables organizations to leverage less technical resources to implement BDD, freeing up development resources, changing the creation area as illustrated below:
Conclusion
BDD is a powerful development practice that can ensure that the correct functionality is being built. Scaling BDD to the enterprise level, however, can be difficult because implementing the practice requires a large pool of technical resources. Parasoft lowers the technical barrier by enabling users to map behavior statements to step execution definitions using a much simpler syntax than Java, .NET, or other programming languages. The step definitions are executed as SOAtest tests, making it much easier for testers and non-technical staff contribute to the verification process.
https://blog.parasoft.com/how-and-why-to-adopt-bdd-in-software-development