Weâ€™ve written about the importance of testing before. If youâ€™re in development, youâ€™re no doubt familiar with agile methodology. But sometimes a test-driven approach seems at odds with going fast. And how do you best communicate the importance of testing to everyone on your team? If youâ€™ve felt frustrated with test-driven development or donâ€™t have buy-in from your team, behavior-driven development is there to help.
Letâ€™s delve into why you should use behavior-driven development and how to implement it. Plus, weâ€™ll discuss tips and tools to make behavior-driven development work best for you.
What Is Behavior-Driven Development?
As a developer, how do I know that the software I wrote is working? Why, test it, of course! Test-driven development (TDD) describes how to do this: First, write the test (that way youâ€™re clear on what your objective is). Then, write the code to make the test pass. Great! Now what?
Though TDD provides a framework to check whether the code you wrote works as expected, it doesnâ€™t provide clear guidance on which features to start with when developing a product. The test functions are also not obvious to people who donâ€™t come from a software development background, which can make communication about the development cycle between the business side and the engineering side of an organization difficult. Itâ€™s these limitations of TDD that behavior-driven development (BDD) wants to improve on.
BDD is a methodology rather than a specific tool. It describes a way of talking about how your software should behave and checking that itâ€™s behaving that way. BDD grew out of a need to not just make tests for the sake of having test coverage, but to direct testing and development to the most important behaviors the software should have. It also gives a framework for talking about tests between the business side and the tech side.
So how do you describe behavior? In BDD, user stories are supplemented with executable scenarios written in a clear, standardized way. In this way, development always follows from clear business needs and the desired outcome is explicitly stated.
But before diving into specifics, letâ€™s discuss why you should use BDD.
Why Use Behavior-Driven Development?
Communication between business and development isnâ€™t always as good as it should be. Engineers may feel tempted to add features that are â€œfunâ€ rather than features that add the most business value. Managers may not understand why development takes longer than they feel it should, especially if they arenâ€™t included in the process. And no one ever said, â€œBoy, I wish I could write some more documentation on this project!â€
So how can we improve communication between business and development? BDD aims to solve that problem.
BDD aims to improve communication among the business side, testers, and developers. It also acts as a road map for developers to focus on the most important features firstâ€”that is, the features that clearly add value.
BDD promotes giving useful names to tests so that itâ€™s easier to take action if a test fails. Tests are written in plain English so that the code is self-documenting. That means that you can avoid undocumented code and onboarding troubles.
Lastly, BDD aims to make the test process more intuitive to newcomers and nonengineers.
How to Implement BDD
BDD principles can be applied to any type of testing, but because of their focus on behavior, they lend themselves best to functional tests. Youâ€™ll remember that instead of a â€œtestâ€ weâ€™re going to talk about â€œbehavior.â€ In this vocabulary, functional tests become â€œthe specifications of the behavior of the product.â€
The emphasis on â€œspecificationâ€ highlights a core viewpoint of BDD: that the creation of unit tests and the creation of features and functional tests are really two sides of the same coin. BDD emphasizes that these two activities shouldnâ€™t be seen as separate. According to Daniel Terhorst-North, the creator of BDD, this vision grew out of the need to have increased collaboration among developers, testers, and domain experts.
Writing the User Story and the Given-When-Then Statement
The desired behavior should come out of the standard user story framework:
As a (role),
I would like (feature)
so that (benefit)
But weâ€™ll add more. A core element of BDD is that user scenarios are written in the given-when-then style, developed by Terhorst-North and Chris Matts.
Given (a specific context)
When (some action is carried out)
Then (a particular set of observable consequences should occur)
A Practical Example
For example, we want to have an â€œadd to cartâ€ feature on an online retail site. The user story might look like this:
Scenario: Add item to shopping cart
As an online customer,
I would like to be able to click on â€œadd to cartâ€ for each item
so that the item is saved to my shopping cart
We can flesh it out into testable format with the given-when-then style. Be specific in what needs to happen. That said, test one thing, and one thing only! You can add more tests for different behaviors.
A user is looking at an item on the website
| item | | ---- | | book | | coat | | shoes|
The user clicks on â€œadd to cartâ€ for the item
That item is added to the userâ€™s cart
| item | | ----- | | book | | coat | | shoes |
Nice! We have an easily understandable and executable scenario to test.
Given-When-Then: A More Complex Example
We can expand on the basic given-when-then structure by adding constructors such as â€œand.â€ Hereâ€™s a given-when-then statement for processing payment:
Scenario: Credit card payment
The user pays for the item via credit card
the credit card details are valid
there is sufficient credit on the account
The user clicks â€œsubmit paymentâ€
$50 is deducted from the userâ€™s credit card
$50 is added to the store account
the purchase is recorded as successful
Tips on Writing Good Scenarios
- Remember that test names should be as expressive as possible. BDD originally started from the idea that a test name should be a sentence describing the exact outcome that should occur. In this way, the test suite becomes the documentation for the software.
- A single test can only test behavior that can be described in a single sentence!
- Write the test name in simple business language so that everyone in the business can understand it.
- The focus is all about business value. As you finish with one test and move on to the next, you should ask, â€œWhatâ€™s the next most important thing that the software should do?â€ Now let this guide your development. (See how development is now not only test driven, but also value driven?)
Limits of Behavior-Driven Development
Like any method, BDD isnâ€™t without its critics. Some drawbacks to note are as follows:
- BDD requires careful specification before any development happens, which may slow a team down.
- You need a content expert for domainâ€“specific language surrounding desired behavior. If your content expert is in high demand, this can become a bottleneck for the team.
- Itâ€™s easier for developers who are already experienced in TDD to switch to BDD than it is for newcomers.
- BDD is also not a cure for everything. In organizations with siloed teams or where increased cooperation among teams isnâ€™t a priority, BDD may just add work for testers.
Behavior-Driven Development Tools
There are various tools available to get started with BDD. BDD was originally implemented in JBehave for Java. Cucumber is a very popular cross-platform tool that turns the Gherkin languageâ€™s given-when-then scenarios into automated test suites. BDD packages are also available for Python, Ruby, and .NET, to name a few.
Are you interested but unsure where to start? If you want to validate the behavior of your code without committing to automated testing, Prefix offers a solution. It runs in your browser to review your code performance. Just note that it only supports .NET or Java web applications on Windows.
Behavior-driven development can help you improve collaboration and automation. One test for one feature ensures that problems can be easily traced. So even if you arenâ€™t using BDD-specific tools, you can use the BDD principles to write better tests.