What is Behavior-Driven Development (BDD)?
Behavior-Driven Development is a way to build and deliver better software. It’s about building software that works well and is easy to change and maintain, but more importantly, it’s about building software that provides real value to businesses.
Businesses want software that’s built well and they need software that’s worth building.
A common risk with software development includes communication breakdowns between developers and business stakeholders
What business problems are you trying to solve?
Software projects fail for many reasons. The two most significant causes are:
■ Not building the software right
■ Not building the right software
Building the software right
Many projects suffer or fail because of software quality issues. Although internal software quality is mostly invisible to nontechnical stakeholders, the consequences of poor-quality software can be a painful experience. Applications that are poorly designed, badly written, or lacking well-written automated tests tend to be full of bugs, hard to maintain or change, and hard to scale.
Software development companies that embrace high-quality technical practices consistently have low to near-zero defect rates and produce code that’s much easier to adapt and extend as new requirements emerge and new features are requested.
Building the right software
Software is not developed in a vacuum. Software projects are part of a broader business strategy, and they need to be aligned with business goals if they’re to be beneficial to the organization. At the end of the day, the software solution you get needs to help users achieve their goals more effectively. Any effort that doesn’t contribute to this end is waste. In practice, there’s often a lot of waste. In many projects, time and money are spent building features that are never used or that provide only marginal value to the business.
According to the Standish Group’s CHAOS studies, on average some 45% of the features delivered into production are never used. Even seemingly predictable projects, such as migrating software from a mainframe system onto a more modern platform, have their share of features that need updating or that are no longer necessary. When you don’t fully understand the goals that your client is trying to achieve, it’s very easy to deliver perfectly functional, well-written features that are of little use to the end users.
Many software projects are not based on delivering real business value. Not only are the features they deliver of little use to the business, they fail to even deliver the minimum capabilities that would make the projects viable.
A better way to develop software
What if you could have software written in a way that would enable the discovery of what really matters and have efforts focused on that? What if you could objectively learn what features will really benefit your organization and the most cost-effective way to implement them? What if you could see beyond what your customers ask for and build what your customers really need?
For years, we’ve been helping businesses achieve these goals. Nexus Software Systems' development teams successfully collaborate to build and deliver more valuable, more effective, and more reliable software. And we do this faster and more efficiently.
Behavior-driven development (BDD) is an agile software development process that encourages collaboration among developers, quality assurance testers, and client representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.
BDD is designed to help teams build and deliver more valuable, higher quality software faster.
BDD draws on Agile and lean practices including, in particular, Test-Driven Development (TDD) and Domain-Driven Design (DDD). But most importantly, BDD provides a common language based on simple, structured sentences expressed in English (or in the native language of the stakeholders) that facilitate communication between project team members and business stakeholders.
Behavior-Driven Development Challenges
While its benefits are significant, introducing BDD into an organization isn’t always without its difficulties. The following are a few situations where BDD can be more of a challenge.
BDD requires business engagement and collaboration
BDD practices are based on conversation and feedback. These conversations drive and build the team’s understanding of the requirements and of how they can deliver business value based on these requirements. If stakeholders are unable or unwilling to engage in conversations and collaboration, or they wait until the end of the project before giving any feedback, it will be hard to get the full benefits of BDD.
BDD works best in an Agile or iterative context
BDD requirements-analysis practices assume that it’s difficult, if not impossible, to completely define the requirements upfront, and that these will evolve as the team (and the stakeholders) learn more about the project. This approach is naturally more in line with an Agile or iterative project methodology.
Poorly written tests can lead to higher test-maintenance costs
Creating automated acceptance tests, particularly for complex web applications, requires a certain skill, and many teams starting to use BDD find this a significant challenge. If the tests aren’t carefully designed, with the right levels of abstraction and expressiveness, they run the risk of being fragile. And if there are a large number
of poorly written tests, they’ll be hard to maintain. Plenty of organizations have successfully implemented automated acceptance tests for complex web applications, but it takes know-how and experience to get it right.
Behavior-Driven Development Benefits
Reduced waste
BDD is all about focusing the development effort on discovering and delivering the features that will provide business value, and avoiding those that don’t. When a feature is built that’s not aligned with the business goals underlying the project, the effort is wasted for the business. Similarly, when a team writes a feature that the business needs, but in a way that’s not useful to the business, the team will need to rework the feature to fit the bill, resulting in more waste. BDD helps avoid this sort of wasted effort by helping teams focus on features that are aligned with business goals. BDD also reduces wasted effort by enabling faster, more useful feedback to users. This helps teams find problems and make changes sooner rather than later, when they are much more expensiveness to fix.
Reduced costs
The direct consequence of this reduced waste is to reduce costs. By focusing on building features with demonstrable business value (building the right software), and not wasting effort on features of little value, you can reduce the cost of delivering a viable product to your users. And by improving the quality of the application code (building the software right), you reduce the number of bugs, and therefore the cost of fixing these bugs, as well as the cost associated with the delays these bugs would cause.
Easier and safer changes
BDD makes it considerably easier to change and extend your applications. Living documentation is generated from the executable specifications using terms that stakeholders are familiar with. This makes it much easier for stakeholders to understand what the application actually does. The low-level executable specifications also act as technical documentation for developers, making it easier for them to understand the existing code base and to make their own changes.
Last, but certainly not least, BDD practices produce a comprehensive set of automated acceptance and unit tests, which reduces the risk of regressions caused by any new changes to the application.
BDD helps teams focus their efforts on identifying, understanding, and building valuable features that matter to businesses, and it makes sure that these features are well designed and well implemented.
BDD practitioners use conversations around concrete examples of system behavior to help understand how features will provide value to the business. BDD encourages business analysts, software developers, and testers to collaborate more closely by enabling them to express requirements in a more testable way, in a form that both the development team and business stakeholders can easily understand. BDD tools can help turn these requirements into automated tests that help guide the developer, verify the feature, and document what the application does.
BDD isn’t a software development methodology in its own right. It’s not a replacement for the methodology you’re currently using.
BDD incorporates, builds on, and enhances ideas from many methodologies. And no matter which methodology you’re using, there are ways that BDD can help make your software better.
One way of looking at BDD, is that it’s a continued development of test-driven development (TDD) which makes more specific choices than TDD. Behavior-driven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
Following this fundamental choice, a second choice made by BDD relates to how the desired behavior should be specified. In this area BDD chooses to use a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design. The scenario aspect of this format may be regarded as an application of Hoare logic to behavioral specification of software units using the domain-specific language of the situation.
BDD specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of user stories, which are each explicitly written down in a dedicated document.
Each user story should, in some way, follow the following structure:
Title An explicit title.
Narrative A short introductory section with the following structure: As a: the person or role who will benefit from the feature; I want: the feature; so that: the benefit or value of the feature.
Acceptance criteria A description of each specific scenario of the narrative with the following structure:
- Given: the initial context at the beginning of the scenario, in one or more clauses;
- When: the event that triggers the scenario;
- Then: the expected outcome, in one or more clauses.
The scenarios are ideally phrased declaratively rather than imperatively — in the business language, with no reference to elements of the user interface (UI) through which the interactions take place
Focus on features that deliver business value
Uncertainty about requirements is a major challenge in many software projects, and heavy upfront specifications don’t work particularly well when confronted with a shifting understanding of what features need to be delivered.
A feature is a tangible, deliverable piece of functionality that helps the business to achieve its business goals. For example, suppose you work in a bank that’s implementing an online banking solution. One of the business goals for this project might be “to attract more clients by providing a simple and convenient way for clients to manage their accounts.” One feature that might help achieve this goal could be “Transfer funds between a client’s accounts”.
Wherever possible, these examples are automated in the form of executable specifications, which both validate the software and provide automatically updated technical and functional documentation.
BDD principles are also used at the coding level, where they help developers write code that’s of higher quality, better tested, better documented, and easier to use and maintain.
For example, using Catch2, which is mainly a unit testing framework for C++ with support for simple BDD macros. You could create the following scenario:
SCENARIO("Transferring money to a savings account", "[bdd]")
{
GIVEN("I have a checking account with 2000.00") {
BankAccount checkingAccount;
checkingAccount.deposit(2000.00);
REQUIRE(checkingAccount.getAccountBalance() == 2000.00);
AND_GIVEN("And I have a savings account with 3000.00") {
BankAccount savingsAccount;
savingsAccount.deposit(3000.00);
REQUIRE(savingsAccount.getAccountBalance() == 3000.00);
WHEN("When I transfer 500.00 from my checking account to my savings account") {
checkingAccount.withdraw(500.00);
savingsAccount.deposit(500.00);
THEN("I should have 1500.00 in my checking account") {
REQUIRE(checkingAccount.getAccountBalance() == 1500.00);
AND_THEN("I should have 3500.00 in my savings account") {
REQUIRE(savingsAccount.getAccountBalance() == 3500.00);
}
...
The unit tests within the scenarios are mapped directly to actual code classes and methods. The results of running provide a detailed report of any errors found and exactly where they’re located. This helps with the design of the application. Ensuring effort is being applied to only what provides business value. And it gives you confidence that everything is working as it should. Producing the expected behavior. This is known as executable specifications.
Unlike conventional unit or integration tests, or the automated functional tests many QA teams are used to, executable specifications are expressed in something close to natural language. They use precisely the examples that the users and development team members proposed and refined earlier on, using exactly the same terms and vocabulary. Executable specifications are about communication as much as they are about validation, and the test reports they generate are easily understandable by everyone involved with the project.
These executable specifications also become a single source of truth, providing reference documentation for how features should be implemented.
Conclusion
Building software right and building the right software are two different things. You need to do both in order to succeed.
Behavior-Driven development is about streamlining the whole development process and delivering value.
With behavior-Driven development you discover and describe the behavior that will deliver real business value. The enables you to avoid wasted effort, improve the software quality and significantly reduce rework.
How you can improve your software with Behavior-Driven development
Learn how you can get better software with behavior-driven development
Related services: Custom Developed Software
References:
