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.
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.
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.
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.
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)
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.
Given
A user is looking at an item on the website
| item | | ---- | | book | | coat | | shoes|
When
The user clicks on “add to cart” for the item
Then
That item is added to the user’s cart
| item | | ----- | | book | | coat | | shoes |
Nice! We have an easily understandable and executable scenario to test.
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
Given
The user pays for the item via credit card
AND
the credit card details are valid
AND
there is sufficient credit on the account
When
The user clicks “submit payment”
Then
$50 is deducted from the user’s credit card
AND
$50 is added to the store account
AND
the purchase is recorded as successful
Like any method, BDD isn’t without its critics. Some drawbacks to note are as follows:
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.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
