Course Overview

Course Overview

Hello everyone. My name is Marko Vajs, and welcome to my course, Behavior-Driven Development: The
Big Picture. This course is a high-level overview of a popular software development methodology that's
been gaining momentum over the past several years. This course is going to provide you with a
high-level overview of what behavior-driven development is. Some of the major topics that we'll cover
include components and concepts of behavior-driven development, where behavior-driven
development can be applied, and what tools you can use as a methodology practitioner. By the end of
this course, you'll have a high-level understanding of behavior-driven development. Before beginning
this course, you should be familiar with agile software development. I hope you'll join me on this
journey to learn how to be more agile with Behavior-Driven Development: The Big Picture course, at
Pluralsight.

Introduction to Behavior-driven Development

Introduction

Hi, and welcome to my course, Behavior-Driven Development: The Big Picture. This course is a high-level
overview of a popular agile software development methodology that's been gaining momentum over
the past several years. In this course, I'll address the following questions among many others. What is
behavior-driven development? What problems it solves? When to use it? What are some of the popular
tools and frameworks for behavior-driven development? And help you assess whether behavior-driven
development is the right choice for you and your team. By the end of this course, you'll have a more
profound knowledge of behavior-driven development, its concepts, and tools you can use. You'll also
know if it's the right choice for your team and where to continue your learning. Even though this course
is about methodology, I'll show you some tools you can use to practice it. Here are the versions of tools
and frameworks shown in this course. Let's start by learning what behavior-driven development is.

What Is BDD?

Let's first see what behavior-driven development is. Behavior-driven development is a software
development methodology that encourages collaboration among developers, test engineers, and
business representatives when working on a project. And why is that important? In agile projects, the
requirements are discovered using user stories that teams discuss throughout the project. Having a
different understanding of requirements is the root cause of many problems, such as software defects,
delivery delays, and features that aren't solving business problems. The later the issue occurs, the higher
cost of fixing it, and most of those issues can be prevented at their source, the analysis of requirements.
Behavior-driven development was first introduced by Dan North in attempt to bridge the gap between
software and business requirements by making tests and test results business readable. We write tests
to ensure our application works as expected. Dan North explained that the easiest way to verify whether
the tests expressed the expected behavior was to show them to the business representatives in a form
they could understand and get early feedback, and getting early feedback is one of the most critical
things in agile software development. In behavior-driven development, every test is an example, and
every example expresses the required system behavior. Examples are written in business language, so
the people from the business can understand them, give feedback, and remain engaged. By creating
examples, we are documenting requirements, removing ambiguities, gaining shared understanding, and
identifying potential issues which lowers the risk of delays, reworks, and defects in the later stages of
software development. Examples are generated from acceptance criteria during user story refinements.
They help us explore the understanding of criteria. The better the examples, the better the chance of
delivering a successful product. Examples are then formulated into scenarios using the Gherkin, a
business-readable language for describing behavior without going into implementation details. Gherkin
follows the given, when, then syntax which describes the context, action, and outcome of the scenario.
And finally, scenarios are automated in a programming language. As long as automated scenarios pass,
we can be sure that our application behaves as intended.

TDD vs. BDD

Let's talk about test-driven development and see how it compares with BDD. Test-driven development is
a software development practice that focuses on creating unit tests before developing the actual code.
In test-driven development, the test process drives the software development by ensuring that the
reason code is covered by at least one test which increases confidence in code and eliminates code
duplication. Test-driven development was designed to help teams build features of higher quality and
speed up the development process. It follows the red/green refactor cycle. Based on user requirements,
a developer writes an automated test for the behavior they are about to implement. When first run, the
test fails since the production code for that feature doesn't exist yet. Then the developer writes the
production code, but only enough to pass the test. That means that performance and other code
optimization concerns are not in focus. And finally, the developer improves the written code. A
previously written unit test provides a safety net that supports refactoring because it ensures that the
behavior stays the same and nothing breaks. Generally, tests should not be changed in the refactoring
stage. Then we have behavior-driven development, an extension of test-driven development where
instead of writing tests, we start by capturing desired behaviors in the form of examples. It follows a
similar cycle where tests are written before the code that makes the tests pass. Teams who use
behavior-driven development often use test-driven development to ensure the validity of the low-level
code. BDD and TDD are very similar. In both practices, a developer writes a test before writing code that
makes the test pass. And in both cases, the test can be part of a continuous integration pipeline to
prevent bugs. Behavior-driven development is designed to test the application's behavior from the end
user's perspective. First, test-driven development is focused on testing smaller pieces of functionality in
isolation. BDD involves product managers, developers, and test engineers collaborating to create
concrete examples of desirable functionality. That means there is a high level of communication before
any implementation. On the other hand, TDD can be done by a sole developer. Tests created using
behavior-driven development are understood by technical and non-technical persons, while TDD tests
are only understood by tech people. Over the past several years, test-driven development has become
frequently adopted in agile environments. Behavior-driven development represents evolution beyond
test-driven development. Their business goals can be better communicated to developers by bridging
the gap between business and tech. Behavior-driven development helps teams to identify potential
problems with user stories, reduce confusion about acceptance criteria, and ensures that the application
functions is expected for end users.

Benefits of Adopting BDD

There are many benefits to adopting behavior-driven development. Some of those benefits can be easily
measured. For example, reduced time to complete tasks is a product of fewer defects found during
development, which can be associated with increasing mutual understanding and identifying edge cases
and ambiguities before starting the development. Detecting defects earlier results in a lower number of
production issues. A better understanding of the features the team is building reduces reworks and
rejections, and consequentially, such an optimized delivery process costs less money, but besides
directly measurable benefits, there are others that cannot be measured so easily, such as higher
confidence in the quality of the product, which is a product of increased test coverage, test pass rate,
lower number of reported defects, user acceptance testing results, reduced code review time, and many
other metrics. Increased collaboration between developers, testers, and business representatives builds
relationships, increasing individual productivity, and motivation. Through collaboration, user stories are
discovered more thoroughly, and the knowledge of certain aspects of the product is shared between
participants that results in increased knowledge of the product domain within the team, but keep in
mind that the BDD itself is not a silver bullet. It's a methodology that, if practiced well, can yield
benefits, and those benefits depend on the extent of BDD implementation. Some teams only write tests
in so-called BDD style without practicing other aspects of behavior-driven development. And that can
also be beneficial due to having business-readable tasks that serve as the documentation and can be
easily debugged, but not all projects can benefit from BDD. In some environments, BDD can be
ineffective. Attempting to fully implement BDD without being able to involve business or keep the
scenarios up to date is usually a recipe for failure.

The BDD Process and Workflow

Discovery of User Stories

Let's explore the phases of behavior-driven development. Behavior-driven development is a structured

process that consists of three parts: the discovery of user stories through examples, formulation of
examples into scenarios, and automation of those scenarios. These activities repeatedly occur for each
small incremental functionality which is in the agile world represented with a user story. Let's first talk
about the discovery of user stories since that's the starting point of each behavior-driven development
cycle. The discovery part is all about discovering requirements, and please, don't confuse this with
gathering requirements. Discovery requires initial requirements to be present, usually in the form of
business rules or acceptance criteria. The discovery requires all team members with different technical
backgrounds and a business representative, typically a product owner, to work together and analyze the
user story. The goal is to generate just enough examples to describe the behavior of a system, so there is
no space left for ambiguities and misunderstandings. There's a technique that can be used to structure
and ease this process. It's called example mapping. Here's how it works. Business rules are written on
sticky notes and placed in a row. Then, participants collaborate to define examples for each rule.
Examples are written on sticky notes and placed under corresponding rules. This process is where the
edge cases, ambiguities, and missing information are discovered. If there are questions that participants
cannot answer or figure out, they should be written on separate sticky notes. A user story is discovered
when there are no unanswered questions, that means discovering a user story may require more than
one session to acquire all necessary answers.

Formulation of Scenarios
When the team has defined examples, it is ready to proceed to the next phase, formulation. The
formulation is a process of turning a shared understanding of how a system should behave into a
business-readable specification. This activity should also be collaborative, especially when a team needs
more experience with the behavior-driven development. Collaboration is required to ensure that the
language used in scenarios will have the same meaning for all stakeholders and all team members. In
experienced teams, formulation should also be collaborative, but could have fewer participants. For
example, it is enough that the QA and the developers sit together and translate examples into scenarios.
Besides common language, it is also necessary to ensure that the particular format is used when
formulating scenarios. The most commonly-used format is Gherkin. Gherkin is a syntax. It is designed to
be a non-technical and human-readable way of describing behaviors in software. It uses a set of
keywords to give a structure to plain text, so automation software can understand it. Here's a simple
scenario written in Gherkin. Let's examine it line-by-line. A feature file, which is a file type readable by
automation software, must start with a feature keyword, and that's the place to give a descriptive name
to the feature. Each feature can contain one or more scenarios. A scenario describes a single example of
a system's behavior, and it should have a descriptive name. Each scenario is made up of one or more
steps. Given and when and then are step keywords. Given is used to describe the context relevant to the
concrete scenario. You can think of it as the application state before the action occurs. When describes
the test action that causes the system to behave in a particular way, and there should be only a single
one in a scenario. The then keyword describes the outcome of previous steps. Also, a scenario should
only have a single then. And finally, we have and and but. But it is not present in this example, but these
keywords are used after given, when, and then to extend them, if needed. In this example, the given line
explains the context. The user is on the product page. When the user clicks on the Add to cart button is
the moment of action that will cause the change in the system state. And finally, the last two lines
represent the then part, whereas the second line extends the first one and further elaborates on the
expected outcome. Code wise, these two lines will be connected to different methods once this scenario
is automated.

Transforming Scenarios into Executable Specifications

Automation is the end phase of the behavior-driven development cycle. It's where scenarios are
transformed into executable specifications that provide valuable feedback for the business and the
entire development team. In this phase, each step from the scenario is implemented using a
programming language to execute the described behavior. Steps are connected to their
implementations using step definitions. That means we can only have the same two steps that do
different things if we put them in a different scope. Testing frameworks treat each feature file as a
separate test suite and each scenario as an individual test. A complete scenario is executed by executing
every step in their respective order. In case there's a step that's not implemented, the scenario will fail.
Automated scenarios have a dual purpose. They act as both tests and living documentation, that means
that they not only verify the behavior of the software, but also serve as detailed human readable
documentation of how the software should work, and as long as those tests pass, we can rest assured
that the documented behavior matches the actual behavior of the software.

Implementing BDD in Real-world Projects

A Successful Implementation of BDD

In this module, I'll share the story of a successful BDD implementation and teach you how to identify
situations where you can apply behavior-driven development. Let's look at the example of one
company. To avoid using its actual name, I'll use the name Globomantics to tell the story. This company
started practicing behavior-driven development to solve multiple issues affecting the quality of their
product on ecommerce platform. Let's first see what their challenges were. The first problem was
understanding the requirements. The development team was asked to integrate with the new payment
gateway with a minimal interface assuming the new payment gateway would handle errors and provide
descriptive messages to the users in case of payment failures or discrepancies. The integration testing
was limited, and test engineers could not execute all the test cases they wanted. When the feature was
rolled out, customers were confused because payment failures resulted in generic error messages,
leaving them frustrated and uncertain about how to proceed, and the product management was
disappointed with the solution as they had expected a user-friendly payment experience. Another
problem was that preserving domain knowledge had become a critical challenge due to high turnover
rates among team members. The complexity of the application and lack of documentation were causing
difficulties in maintaining the system and adding new features. By implementing behavior-driven
development, Globomantics was able to bridge the gap in communication and understanding between
development and product management teams. The development team collaborated with business
representatives to come up with examples and formulate them into scenarios using Gherkin. The
Gherkin scenarios clearly outlined expected behavior for payment method selection, user interface
elements, error messages, and user feedback, and expectations are well understood from both sides.
Once submitted, scenarios ensured the developed code aligned with the intended behavior. Regular
feedback loops allow the development team and business to review and refine specifications and timely
address any ambiguities and discrepancies. Furthermore, capturing the expected system behavior in a
way accessible by technical and non-technical people helped them onboard new team members. They
could quickly understand how different parts of the applications are supposed to work by reading and
running the executable specifications. The reliance on individuals knowledge was reduced as the
documentation to executable specifications became a primary source of information, and the
developers could confidently make changes to the application knowing that executable specifications
and tests ensured they were not introducing unintended behavior.

When to Apply Behavior-driven Development

Behavior-driven development addresses several challenges in software development by promoting

collaboration, clear communication, and a focus on delivering business value, and those are the
challenges, such as miscommunication between developers, test engineers, and business
representatives. By discussing scenarios, everyone gains a shared understanding of the desired behavior
with increased frequency of communication. A problem with low-quality communication is also
addressed. The absence of clear requirements which often slows down the development and results in
missed deadlines, reworks, and rejections. Scenarios serve as a clear and concrete development guide
ensuring that the software behaves as expected. Since scenarios are written from a user's perspective,
focusing on how the software will be used, how should meeting needs and expectations of end users. It
also addresses the late detection of defects. Since behavior-driven development promotes writing tests
early in development. These tests identify differences in behavior and prevent them from escalating into
severe and expensive issues. It also helps bridge the documentation gaps where documentation
becomes obsolete if not maintained. Scenarios are part of the development process and are maintained
alongside the code base. And by automating scenarios, the test coverage is improved. Not all types of
software development projects are suitable for behavior-driven development. Behavior-driven
development is highly effective for projects where the application's complexity requires a clear
understanding of user interactions and behaviors. On the other hand, BDD might be an overhead on
simple and well-defined projects. These projects might find traditional development methods more
efficient. Behavior-driven development is a valuable approach when project requirements are
ambiguous or subject to change. BDD helps clarify requirements through collaboration and continuous
feedback. On the other hand, if such a project lacks regular collaboration between developers, test
engineers, and management, implementing behavior-driven development might be challenging. BDD
works best in agile environments where iterative development is practiced. Such projects usually involve
collaboration between developers, test engineers, designers, product owners, and business
stakeholders and have regular feedback loops and are highly adaptable to changing requirements. Fixed
scope, low budget, and time constraint projects are not the best candidates for behavior-driven
development. Projects with fixed scope and tight deadlines might find it challenging to accommodate
the flexibility BDD offers. Furthermore, documenting scenarios and collaboration requires additional
time and resources which might be difficult in low budget projects. Behavior-driven development is
valuable for projects aimed at enhancing or modifying legacy systems. It helps preserve domain
knowledge and prevent unexpected changes during updates. And lastly, we have the research and
development projects where the BDD structured and scenario-driven approach might cause more harm
than benefits. Such projects often prioritize exploration over detailed specifications.

Tools and Resources for BDD

Exploring Tools for BDD Practitioners

Many tools can improve the behavior-driven development process. In this clip, I'll show you two tools
you can use to create examples and formulate scenarios. The first tool is Google Drawings. Google
Drawings is a diagramming software included in Google's web-based suite, but did you know it can be
also used to practice Example Mapping, a technique in behavior-driven development. Example Mapping
is a collaborative practice that helps teams define and clarify requirements in a structured manner. It
involves breaking down features into smaller pieces and creating examples of desired behavior for each
piece. Google Drawings can be the canvas for this process. Here's how. In Google Drawings, you can
create a blank canvas to represent the user story visually. Start by writing the user story under
discussion on a yellow sticky note or a card and placing it at the top of the canvas. Next, write
acceptance criteria on blue cards and place them beneath the yellow card. For each rule, we may need
one or more examples to illustrate it. We write those on green cards and place them under the relevant
rule. As we discuss these examples, we may uncover questions that nobody in the room can answer, we
capture those on red cards and move on with the conversation. We keep going until the group is
satisfied and the scope of the story is clear or we run out of time. Lines can be used to link examples to
related questions and user stories. They visually illustrate their relationship and dependencies between
different parts of the feature. Since Google Drawings is collaborative, team members can contribute
simultaneously. Discussions around examples and behaviors become more tangible and efficient.
Another tool that can help with collaborative activities is Behave Pro, which is a Jira extension. Behave
Pro is designed to enhance the implementation of behavior-driven development by integrating it
directly into Jira environment, making it easier for teams to create, manage, and collaborate on
scenarios. Once I have added the extension from the Atlassian Marketplace, I need to configure it. First, I
need to select the version control system I want to use to store scenarios. I'll select Bitbucket and
connect my account. For the integration type, I'll choose New since we want full integration with the
tool. And finally, I'll select the organization, repository, and branding strategy. Here, we can specify the
path where to commit feature files. If you are using Java, you can specify these paths to store feature
files. I'll accept the default value since this repository is currently empty. Okay. Let's now create a story
for the feature that should enable users to add items to the cart, and let's set the few acceptance
criteria. Okay. When I open the story, I'll get a new section from the Behave Pro extension. Using this
section, I can write scenarios straight from Jira. I can select an existing feature or add a new one, and I
can write steps in Gherkin. Once I'm done, I'll save the changes. By default, every scenario is marked as
automated, and we can additionally integrate this with the continuous integration server to get
execution results directly in Jira. I won't do that now, but here you can find the guide on how to do it.
Adding a scenario makes a commit to the repository and tags the scenario with the Jira issued key. Since
we have chosen a feature-based branching, a new branch will be created every time. Once this branch is
merged, we'll be able to see this feature outside the story in the features repository in Jira. There are
other tools similar to Google Drawings and Behave Pro that can be used to support behavior-driven
development practices. I encourage you to do a bit of research to find the one that works the best for
you and your team.

Exploring BDD Frameworks and Plugins

When it comes to automation, there are tools and ID plugins designed specifically for behavior driven
development. The choice will depend on the programming language you want to use to write codes that
will execute steps from feature files. Let's look at some of them in Java. The most popular BDD
framework is Cucumber by far. Cucumber supports step definitions where the king steps are linked to
Java code enabling the implementation of the desired behavior. It can be integrated with popular IDs
like intelli and eclipse ID plugins provide syntax highlighting code, navigation and test execution
features, availability of features varies across programming languages. You can find links to the official
documentation for all supported programming languages on the cucumbers, official website. Let's take a
look at an example where i'll use Java with cucumber to automate a previously written scenario. You
don't have to code along, just sit and watch. Here's the future file I have previously created. I have also
created a new Java Cucumber project and placed this file inside source test resources directory. If I
choose to run this, i'll get an errors that this scenario contains steps that are not implemented since I
have the cucumber plug-in for Intel, I can choose to generate step definitions for all steps inside this file.
And i'll select the existing file. If I open this file, i'll see new methods generated for each step, I'll
implement this scenario using selenium. Let's first look at the application. So we have to navigate to the
product's page, click the add to cart button and verify that the item has been added to the card and that
the total number of items in the cart equals one. So I have previously implemented pages. So we don't
have to worry about low level code and focus only on the cucumber. So in the first method, I'll call
products page. Click on the add to cart button for the item and pause the first argument which will inject
the value from the feature file, which is the phone charger text. After this step, the user should be
redirected to the card. So we can write assertions in the last two steps. In the first one, i'll assert that the
phone charger is in the cart. And in the second one, I, the total number of items in the cart is equal to
one and both of these values come from the future file. Ok. Let's run this and check the outcome and all
works is expected. Let's now change the total number of items and check the outcome. As we can see.
The step is now marked as field which caused the entire task to fail. And we can see here exactly why we
can also enable the runner to output the results in the H TM L format to get an easy to read report that
we can make available to others. Getting continuous feedback in a way that highlights passing and failing
scenarios and steps contributes to the living documentation. As long as tests pass, we can rest assured
that our documentation is up to date. And if the tests fail, we either have a regression or need to update
the scenarios.

Using Living Documentation

Living documentation refers to the documentation that is continuously updated and aligned with the
current state of the application. Unlike traditional documentation, which often becomes outdated and
loses its usefulness over time, living documentation serves as a reliable source of information for
developers, test engineers, product owners, and other stakeholders. Automated scenarios represent
living documentation as long as they pass, the documentation is aligned with the current state of the
application. Having living documentation is beneficial in many situations. It serves as a knowledge base
for all the team members, especially the new ones and helps them to discover the system, and existing
team members can use it if they forget how something works. It ensures everyone has a common
understanding of the software's expected behavior, reducing misunderstandings and ambiguities. And
it's easier to maintain than traditional documentation since it's kept in the code base. The quality of the
living documentation depends on the quality of all previous steps in the process. If the language used
during discovery and formulation is not understood by everyone, or if the examples and scenarios are
not made through collaboration, there's a chance that the documentation won't provide the expected
benefits. The key to good examples and scenarios is to form a shared language between technical and
business people to agree on common terms for certain domain items. Another improvement is to link
scenarios to user stories and establish traceability. It allows teams to track test coverage and better
handle changes in requirements. Living documentation needs to be easily accessible to business people.
You can use tools like Behave Pro to integrate it into Jira or other tools that can generate reports
combining future files and test execution results that you can host as a website accessible to relevant
parties. It needs to capture all relevant scenarios and the logic of the application. Not defining scenarios
for certain behaviors results in incomplete documentation. And most importantly, it needs to be kept up
to date. Referring to scenarios that are not automated or ignoring failing scenarios strips the word,
deleting from the documentation, and there's no guarantee it is up to date.

Resources for Additional Learning

Learning behavior-driven development involves understanding the principles, practices, and tools
associated with this methodology. There are books and other resources available to help you learn
behavior-driven development effectively. Here are some recommended resources to start with. The
Discovery and Formulation books that specifically focus on and explain detail of these two phases of
behavior-driven development. Another book is Specification by Example, it covers techniques and
examples to improve collaboration between stakeholders and development teams. Then the official
documentation of BDD frameworks for a specific programming language, such as Cucumber, SpecFlow,
and Behave. And finally, the other courses that will be added to this Pluralsight learning path.
Remember that BDD is not just about tools, it's about collaboration, clear communication, and a shared
understanding of requirements. These resources will help you grasp the concepts and practices
associated with behavior-driven development, allowing you to apply them effectively to your projects. I
want to thank you for taking the time and watching this course. Feel free to rate it and leave a comment
if you have any feedback. Thank you for watching, and good luck on your journey of behavior-driven
development.