Behavior-driven development (BDD) is a way to synthesize practices from test-driven development. It defines the behavior of an application using examples written in a shared language. These examples form the basis for automated tests to ensure the system works as intended. BDD encourages collaboration, works in small iterations with feedback, and produces documentation that can be checked against the system's behavior.

1. BEHAVIOR-DRIVEN
DEVELOPMENT

2. WHAT IS BEHAVIOR-DRIVEN DEVELOPMENT (BDD)?
Behavior-driven development can be defined as a way to
synthesize and define practices that stem from test-driven
development (TDD).
BDD is several things:
• It’s a language used to define the behavior of an application.
• It’s a collaboration tool for product managers, engineers, and testers.
• It’s a system for automatically testing those behaviors.

3. THE BDD APPROACH IS OFTEN DIVIDED INTO TWO MAIN
PARTS:
1.The first part involves using examples that are written in ubiquitous language as a way to
illustrate behaviors or the different ways users interact with the product.
2.The second part is the practice of utilizing those examples as a basis for automated tests. In
addition to allowing developers to check functionality for the user, it also ensures that the overall
system works precisely as defined by the business for the project’s entire lifetime.

4. HOW DOES IT DO THAT?
• By encouraging collaboration across different roles to build a shared understanding of the
problem that must be solved.
• By working in small, rapid iterations to increase feedback and enhance the flow of value.
• By producing system documentation that can be automatically checked against the behavior
of the system.

5. WHAT ARE THE BENEFITS OF BDD?
Strong Collaboration. Thanks to the shared language, product owners, developers, and testers all
have in-depth visibility of the project’s progression.
Shorter Learning Curve. Since BDD is explained using very simple language, there’s a much shorter
learning curve for everyone involved.
High Visibility. Being a nontechnical process by nature, behavior-driven development can reach a
much wider audience.
Rapid Iterations. BDD allows you to respond quickly to any and all feedback from your users so
you can make improvements to meet their needs.
BDD Test Suite. Similar to adopting TDD, adopting BDD gives your team confidence in the form of
a test suite.
Eliminate Waste. BDD allows you to clearly communicate requirements so there’s less rework due
to misinterpreted requirements and acceptance criteria.
Focus on User Needs. Satisfied users are good for business and the BDD methodology allows user
needs to be met through software development
Meet Business Objectives. With BDD, each development can be traced back to the actual business
objectives.

6. WHAT ARE THE DISADVANTAGES OF
BDD?
• To work in BDD, prior exposure to TDD concepts is required.
• Behavior-driven development is not compatible with the waterfall approach.
• Testers using BDD must have sufficient technical expertise.
• BDD may not be effective if the requirements aren’t meticulously specified.

7. IMPLEMENTING THE BDD APPROACH –
THREE PRACTICES
Essentially, day-to-day BDD activity is a three-step, iterative process:
1.First, take a small upcoming change to the system – a User Story – and talk
about concrete examples of the new functionality to explore, discover and agree
on the details of what’s expected to be done.
2.Next, document those examples in a way that can be automated, and check
for agreement.
3.Finally, implement the behaviour described by each documented example,
starting with an automated test to guide the development of the code.

8. The idea is to make each change small and iterate rapidly, moving back up a level
each time you need more information. Each time you automate and implement a
new example, you’ve added something valuable to your system, and you’re ready to
respond to feedback.
We call these practices Discovery, Formulation, and Automation.

9. BEST PRACTICES FOR BDD
1. Avoid Lengthy Descriptions
All features should have only a sensible and short title and description. Feature descriptions that are long are often
boring to read and tend to put off stakeholders. As a general rule, features should be a concise sentence that describes
the scope and context.
2. Choose a Single Format for Your Features
Another best feature for behavior-driven development is to decide the types of formats that you use for writing features.
The format you choose should be consistent across all feature files. This makes it easy for anyone who is new to the
project to easily understand the features and context.

10. 3. Keep the Background Short
Whenever possible, continue to use a background for shared steps that are required for each scenario in your
feature file. The background gets rid of many of the repetitive steps and its proper use can help you avoid duplication in
feature files. Keep your background short, ideally no longer than four lines. It should act as a prerequisite for every scenario in
the future file.
4. Avoid Using Technical Language in the Background
Make sure you avoid using technical stuff (language or actions) during the background step. For instance, you
shouldn’t have a background step for things such as starting/stopping Apache, clearing the cache, truncating database, etc.
since users don’t really care about these things.
5. Don’t Tag the Background
Never tag the background, only the scenarios, and features. Also, never use the background for feature files that
contain just one scenario. This doesn’t make sense since you can include the details directly in the GIVEN step.

11. 6. Consider Scenario or Scenario Outline
In any other instance, you can use “scenario outline” to cover multiple examples. You can use the table for this. And
proper use of scenario outlines will also help to make your scenarios a lot more readable and maintainable, as well as prevent
you from duplicating steps.
7. Keep Scenarios Short
Another best practice for BDD is to hide implementation details and avoid using technical details in order to keep
scenarios short. Long and descriptive scenarios that include lots of “AND” or “BUT” steps become brittle and less readable.
8. Use the Given-When-Then Formula in the Right Order
When writing scenarios, use the right sequence for the GIVEN-WHEN-THEN steps (with the proper use of “AND,”
and “BUT”).
This style of writing makes it easy for anyone to understand since it doesn’t contain any implementation details. It
also highlights the reasons why a specific feature is important for any given persona.

12. 9. Cover Happy and Non-Happy Paths
Your scenarios need to cover not only the happy path where the user has a straightforward journey but
different edge cases surrounding the happy path.
10. Points To Consider for “Tags”
Tagging lets you organize features and scenarios properly in your BDD project. If your feature files span
you can use tags to help filter specific scenarios of features.
For instance, say you have a set of scenarios for Gmail, you can then use the “@mail” tag to mark those
easily search for the @mail tag.
Here are a few more tips concerning tags:
• Use Relevant Tag Names: For instance, you can use @daily, @hourly, or @nightly for frequency of
execution. Likewise, progress can be labeled using @wip, @todo, @implemented, or @blocked, and
so on.
• Tagging Features Smartly: You can tag individual scenarios, but tagging an entire feature may be
useful in some instances. For instance, you might tag a feature using a story number (e.g. @Jira-story
bug tracking system.
• Avoid Unnecessary Tag Use: Don’t tag a scenario using the same tag that you used for a feature. If
you’ve tagged an entire feature, then the scenarios inside the feature automatically inherit the tag. So
unnecessary tags in your project or the result will be overcomplication of your feature files.

13. REMEMBER: PRACTICE MAKES
PERFECT
When dealing with behavior-driven development, there are a ton of rules that you
can use as guiding principles, but only practice will allow you to become an expert in
this smart approach in agile methodology.

14. END!!!

15. QUIZ
1.Can be defined as a way to synthesize and define practices that
stem from test-driven development?
2.By producing __________________that can be automatically checked against
the behavior of the system.
3-7. In any order write at least five (5) Benefits of Behavior-Driven Development.
8.Write one (1) disadvantage of Behavior-Driven Development.
9. All features should have only a sensible and short title and description.
10. The format you choose should be consistent across all feature files.