{"id":28414,"date":"2020-04-13T10:08:38","date_gmt":"2020-04-13T10:08:38","guid":{"rendered":"https:\/\/stackify.com\/?p=28414"},"modified":"2024-03-18T10:20:06","modified_gmt":"2024-03-18T10:20:06","slug":"what-is-behavior-driven-development","status":"publish","type":"post","link":"https:\/\/stackify.com\/what-is-behavior-driven-development\/","title":{"rendered":"What Is Behavior-Driven Development?"},"content":{"rendered":"\n

We\u2019ve written about the importance of testing<\/a> before. If you\u2019re in development, you\u2019re no doubt familiar with agile methodology<\/a>. 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\u2019ve felt frustrated with test-driven development or don\u2019t have buy-in from your team, behavior-driven development is there to help.<\/p>\n\n\n\n

Let\u2019s delve into why you should use behavior-driven development and how to implement it. Plus, we\u2019ll discuss tips and tools to make behavior-driven development work best for you.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

What Is Behavior-Driven Development?<\/strong><\/h2>\n\n\n\n

As a developer, how do I know that the software I wrote is working? Why, test it<\/a>, of course! Test-driven development<\/a> (TDD) describes how to do this: First, write the test (that way you\u2019re clear on what your objective is). Then, write the code to make the test pass. Great! Now what?<\/p>\n\n\n\n

Though TDD provides a framework to check whether the code you wrote works as expected, it doesn\u2019t provide clear guidance on which features to start with when developing a product. The test functions are also not obvious to people who don\u2019t 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\u2019s these limitations of TDD that behavior-driven development (BDD) wants to improve on.<\/p>\n\n\n\n

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\u2019s 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.<\/p>\n\n\n\n

So how do you describe behavior? In BDD, user stories<\/a> 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.<\/p>\n\n\n\n

But before diving into specifics, let\u2019s discuss why you should use BDD.<\/p>\n\n\n\n

Why Use Behavior-Driven Development?<\/strong><\/h3>\n\n\n\n

Communication between business and development isn\u2019t always as good as it should be. Engineers may feel tempted to add features that are \u201cfun\u201d 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\u2019t included in the process. And no one ever said, \u201cBoy, I wish I could write some more documentation on this project!\u201d<\/p>\n\n\n\n

So how can we improve communication between business and development? BDD aims to solve that problem.<\/p>\n\n\n\n

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\u2014that is, the features that clearly add value.<\/p>\n\n\n\n

BDD promotes giving useful names to tests so that it\u2019s 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.<\/a><\/p>\n\n\n\n

Lastly, BDD aims to make the test process more intuitive to newcomers and nonengineers.<\/p>\n\n\n\n

How to Implement BDD<\/strong><\/h3>\n\n\n\n

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\u2019ll remember that instead of a \u201ctest\u201d we\u2019re going to talk about \u201cbehavior.\u201d In this vocabulary, functional tests become \u201cthe specifications of the behavior of the product.\u201d<\/p>\n\n\n\n

The emphasis on \u201cspecification\u201d 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\u2019t be seen as separate. According to Daniel Terhorst-North, the creator of BDD<\/a>, this vision grew out of the need to have increased collaboration among developers, testers, and domain experts.<\/p>\n\n\n\n

Writing the User Story and the Given-When-Then Statement<\/strong><\/h3>\n\n\n\n

The desired behavior should come out of the standard user story framework:<\/p>\n\n\n\n

As a<\/strong> (role),
I would like<\/strong> (feature)
so that<\/strong> (benefit)<\/p>\n\n\n\n

But we\u2019ll 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.<\/p>\n\n\n\n

Given<\/strong> (a specific context)
When<\/strong> (some action is carried out)
Then<\/strong> (a particular set of observable consequences should occur)<\/p>\n\n\n\n

A Practical Example<\/strong><\/h3>\n\n\n\n

For example, we want to have an \u201cadd to cart\u201d feature on an online retail site. The user story might look like this:<\/p>\n\n\n\n

Scenario: <\/strong>Add item to shopping cart<\/p>\n\n\n\n

As an<\/strong> online customer,
I would like<\/strong> to be able to click on \u201cadd to cart\u201d for each item
so that<\/strong> the item is saved to my shopping cart<\/p>\n\n\n\n

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<\/em>! You can add more tests for different behaviors.<\/p>\n\n\n\n

Given<\/strong>
<\/strong>A user is looking at an item on the website<\/p>\n\n\n\n

 | item |\n | ---- |\n | book |\n | coat |\n | shoes| <\/pre>\n\n\n\n
When<\/strong>
<\/strong>The user clicks on \u201cadd to cart\u201d for the item<\/p>\n\n\n\n
Then<\/strong>
<\/strong>That item is added to the user\u2019s cart<\/p>\n\n\n\n
 | item  |\n | ----- |\n | book  |\n | coat  |\n | shoes | <\/pre>\n\n\n\n
Nice! We have an easily understandable and executable scenario to test.<\/p>\n\n\n\n
Given-When-Then: A More Complex Example<\/strong><\/h3>\n\n\n\n
We can expand on the basic given-when-then structure by adding constructors such as \u201cand.\u201d Here\u2019s a given-when-then statement for processing payment:<\/p>\n\n\n\n
Scenario<\/strong>: Credit card payment<\/p>\n\n\n\n
Given<\/strong>
<\/strong>The user pays for the item via credit card
AND
the credit card details are valid
AND
there is sufficient credit on the account<\/p>\n\n\n\n
When<\/strong>
<\/strong>The user clicks \u201csubmit payment\u201d<\/p>\n\n\n\n
Then<\/strong>
<\/strong>$50 is deducted from the user\u2019s credit card
AND
$50 is added to the store account
AND
the purchase is recorded as successful<\/p>\n\n\n\n
Tips on Writing Good Scenarios<\/strong><\/h3>\n\n\n\n