Behavior Driven Development, or BDD, is a branch of principles defined by Test Driven Development (TDD). In TDD, we build the thing right. In BDD, we ensure we build the right thing. The principles and technologies leveraged in BDD have been widely adopted in functional testing. A BDD testing framework includes the likes of Cucumber and SpecFlow, which have enabled non-technical product owners to define application behavior as human-readable text. As those behaviors (or features) translate into test code, the QA team can achieve test automation faster and easier, even with a lack of domain knowledge.
BDD is hardly a new concept in 2021. Most organizations have adopted BDD as the most effective way to translate business requirements into good software. In this article, we highlight some of the main drivers and technologies with a focus on Java.
Business requirements document the needs and purpose of the end product. The requirements will also define users as well as standards that will be used for evaluation. BDD provides shared tools and processes across the entire (technical and non-technical) team to foster collaboration in meeting defined business requirements.
A business requirement translated into a language such as Gherkin can be defined as:
These features (or behaviors) are mapped to test code that can execute the behavior and validate it. In development, the practice is to define the feature BEFORE writing any code. This ensures you’re building the right thing—no more and no less.
Structuring business requirements as a Given/When/Then statement makes it easier to write acceptance tests.
Acceptance tests determine whether or not the requirements of the features being tested meet expectations. This helps to align the software with defined business requirements and ensure specifications have been met. Acceptance tests are an integral part of quality assurance, but defining and executing acceptance tests can be a challenge without domain knowledge or a good functional test automation tool.
Let’s discuss what testing frameworks are, along with some technologies and challenges that you may encounter as you implement the BDD testing framework as your software testing solution.
At a high level, BDD test automation frameworks read executable specifications written in plain English and verify that the tests are successful. BDD also goes hand-in-hand with Agile, enabling development and quality teams to optimize their flows for efficiency.
But adopting BDD is not an overnight venture. The human-readable text must translate into code, and where there is code, there are developers. Typically that test library must be developed and maintained by developers or technical testers (bet you’re calculating how much that’ll cost you). This is where the BDD testing framework tools come into play to help save the day. To transition to the BDD framework, you can depend on functional test solutions that integrate with the BDD framework to assist in defining features.
There are three main steps when applying BDD practices to your testing.
Wash, rinse, repeat. This is where we see the benefit of defining features before writing any code helps to ensure that you are only building what you need—no extra frills (or unnecessary work).
BDD has many benefits in testing. The use of plain English to write tests means they can be written more quickly, even by non-technical team members. Additionally, setup tests and teardown tests, which can be a complex sequence of API calls, can be defined in a “sentence.”
BDD encourages use of Agile methodologies during both development and testing. It enables effective sharing of knowledge on the system and testing requirements among an entire team. Behaviors can also be mapped back to Jira requirements, which can be valuable for traceability and test coverage.
Once your feature files are created, it’s time to automate. Feature files can be executed as part of a DevOps flow or a release pipeline. It is important to have reporting that maps execution results back to the requirements to ensure that the business requirements are consistent with the implementations brought forth by the development team.
As mentioned above, cost savings is a huge benefit. Since users can develop their own libraries and test code using software such as Parasoft Selenic and SOAtest, the reliance on developers to facilitate BDD testing infrastructure diminishes.
The biggest challenge in BDD testing is the need to map the “plain English” text to code, tailored for each feature. Developers are needed to develop the underlying code, and the cost for that time adds up quickly (but don’t forget the benefits mentioned above—all hope is not lost).
Parasoft SOAtest alleviates this challenge through the AI-enhanced creation of scriptless automated API & component tests. Additionally, Parasoft Selenic helps create and maintain Selenium UI scripts. This is a different approach to developing your test library. This also means that nontechnical people can create tests, therefore enabling developers to spend their time developing new features, rather than testing them.
Probably one of your biggest questions about BDD tools so far has been: How do I use BDD without writing code? Testing tools that enable non-technical folks to create their own test library or extend the existing framework can be a crucial step in increasing ROI from BDD.
Cucumber uses Gherkin language to define test cases. It’s a nontechnical language that’s easy to read and uses Given/When/Then statements to structure the behaviors of your software. It also promotes BDD practices and uses clear requirements from the beginning of the process. All these easy-to-use attributes make Cucumber one of the most popular tools in BDD.
A common implementation of Cucumber will run acceptance tests written in JUnit or TestNG, which may be a functional test or Selenium UI test. Features are written in Gherkin, and each step has a step definition that maps the statement to some code.
Each test method corresponds to a sentence, and Cucumber is the Rosetta Stone that makes the translation.
JUnit is a simple framework to write repeatable tests. It is commonly used for unit tests, but it can be efficiently used to drive Selenium WebDriver or even write performance tests. It allows users to write test methods and assertions or set up/tear down code. This code can be called by Cucumber when it reads a Feature step. JUnit5 has added a lot of new features like parameterization, but other common frameworks including TestNG and RSpec have their own advantages.
When organizations have to choose between quality and delivery, they often turn to vendors like Parasoft which have been specializing in software development and test automation for more than 30 years. The following set of tools enables teams to get the most out of BDD.
Parasoft Recorder is a Chrome extension that captures UI action on the webpage, as well as API traffic. These recordings can be mapped to work items, or features, or user story. That metadata can live with the test and tied back to the initial feature for traceability across the SDLC.
JUnit5 and TestNG are often used to drive Selenium UI tests, but not everyone is an expert in Java, so tools like Parasoft Selenic enable users to shift-left with record and playback and self-healing for test automation.
Being able to generate pure Java code by simply recording manual tests maps the test code directly to the business requirement.
API tests are generally difficult to define and require intimate knowledge of the service, as well as the system. Parasoft SOAtest is a tool for scriptless functional test automation but can be used with Cucumber as well. You can simply import a service definition file like Swagger, set up the test, and add data. You can also reuse the recording from the Parasoft Recorder to automatically create API tests, which can then be repurposed for load and performance testing.
The Cucumber integration then allows users to add step definitions pointing to these tests.
BDD provides the ability for the entire team (even the not-so-technical team members) to engage in writing and testing your software. Some of the challenges that come along with BDD, such as mapping plain English (aka nontechnical) text to code, can be solved using solutions like Parasoft Recorder. Overall, BDD is a great guideline to develop the right thing the right way.
Grigori Trofimov is a Solution Architect at Parasoft, providing consulting services for Parasoft’s testing solutions to prospects, customers, and partners. He has spoken at conferences recently on the topic of service virtualization and deployment of disposable environments in the cloud.