Behavior Driven Development
Tags: development, beginners
Published: 2023-06-26 16:55:18

## Intro

Behavior driven development (BDD) is an outside-in approach to software development that promotes understanding in all members of a team. In order to understand BDD, one must first understand test driven development (TDD). BDD takes the general TDD approach, and adds an additional layer of guidance to further flesh out a concrete plan of action. One of the benefits of BDD is that this approach will aid intra-team communication, and thereby streamline efficiency of software development projects. 

## What does TDD have to do with BDD?

These two approaches are not mutually exclusive. In fact, BDD emerged from TDD. TDD, on it's own, is a powerful and effective approach to software development that has changed the way developers implement code. BDD takes this approach and elaborates even further.

## What is TDD?

Test-driven development is a process in which tests are created before code is implemented. First, developers write tests against which they will test their code. These tests are written before the code and therefore should initially fail. Code is then subsequently implemented with the goal of making the tests pass. Thus, development is driven by the tests. 

## How BDD Works: Outside-in

BDD takes the TDD approach and adds a few more layers of specified action. 

**Narrative**


Starting at the top, team members can articulate their goals in the "narrative" phase. At this time, team members use natural language in a specific structure to describe the goals of their software project. That structure is as follows: 

- As a (person's role)

- I want (desired feature)

- So that (benefit/value)

A product owner will use this structured, natural language to articulate a narrative of how their want their product to work. For example, suppose the owner of a grocery store is implementing on online shopping service for grocery delivery. They want customers to be able to view grocery items, add selected items to a cart, and check out. They might articulate the following customer narrative:

"As a grocery store customer, I want to add a desired items to my cart, so that I can purchase them."

Using this natural language makes goals accessible and aids communication among the many members of the project's team, regardless of whether they are familiar with the technology. For example, designers, business owners and quality assurance can participate and communicate effectively.


![Development team](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ui8xoqvk4xk8991zdn6t.png)
[Source](https://asperbrothers.com/blog/software-development-team/)

**Acceptance Criteria**

This structured narrative is then easily translated into clearly stated acceptance criteria. Acceptance criteria are the goals that must be achieved by the software. They are stated in the following structure: Given (initial context), When (event that will trigger a scenario), Then (expectation or outcome).


![Given, When, Then](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sy6citd0n5frp3pj43t6.jpeg)
[Source](https://www.j-labs.pl/blog-technologiczny/given-when-then-pattern-in-unit-tests/)

To continue our online grocery service example, the acceptance criteria would be as follows: "Given that I am browsing items, when I click an item, the item should then be added to the cart."

**Executable Tests**

Now that we have broken down the goals of our software in plain, understandable language, we can translate them into actual tests against which to test our code. Tests should be given descriptive names of whatever behavior they are testing for. Using test methods named actual descriptive sentences helps developers create documentation that everyone on the team can understand.

Here is an example of what some of the tests may look like: 

```
class AddItemToCart extends TestCase {

testAddItemToCollection() {
	…
};

testIncreaseItemCount () {
	…
};

testIncreaseTotalPrice () {
	…
};

(... and so on)
};

```

Now we all team members have been able to contribute thoughts and ideas. Developers are now able to use all of this information to hone in on features of the software, and create specific tests. 

## Conclusion

In conclusion, BDD is a helpful, top-down approach that provides clear structure of how to achieve particular software features. The natural language allows all of the necessary parties to contribute to the project. The structure provides straightforward guidance on how to articulate goals, and how to proceed at each step. Finally, developers can get down to the detailed level of TDD, and implement their code against tests. 

## Sources

- https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/

- https://dannorth.net/introducing-bdd/

- https://dannorth.net/whats-in-a-story/

- https://www.j-labs.pl/blog-technologiczny/given-when-then-pattern-in-unit-tests/

- https://www.rswebsols.com/build-culture-software-development-team/