Introduction to Behavior Driven Development (BDD)

diegogamboamismo

5 years ago

Behavior Driven Development is a set of practices that allows software development teams to work in a way that closes the gap between business and technical people, by:

encouraging collaboration across roles to build a shared understanding of the desired behavior of the system.
producing system documentation that guides the development and is automatically checked against the system’s behavior.
working in rapid, small iterations to increase feedback and the flow of value.

Reducing this way the misunderstanding between teams which is usually reflected as missed requirements, bad assumptions, rework, etc.

BDD and Agile

BDD does not replace an existing agile process. You require an agile process to be in place to do BDD. So, it actually enhances it. You can think of it as a set of plugins that will make your team more able to deliver on the promises of agile: Timely, reliable releases of working software that meets the organization’s evolving needs.

BDD intends to work in rapid iterations, and quickly respond to feedback from the users, while doing only the minimal work necessary to meet those needs. Thus, BDD encourages working in small, rapid iterations, breaking down users’ problems into smaller pieces that can flow through our development process as quickly as possible.

A nice post on how BDD supports agile can be found here.

Key Benefits of BDD

All development work can be traced back directly to business objectives.
Software development meets user needs. Satisfied users = good business.
Efficient prioritization – business-critical features are delivered first.
Helps build what Eric Evans calls a Ubiquitous Language in his Domain Driven Design book.
All parties have a shared understanding of the project and can be involved in the communication.
A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.
Resulting software design that matches existing and supports upcoming business needs.
Improved code quality, reducing costs of maintenance and minimizing project risk.
Code is self-documenting.

How does BDD work?

Basically, it consists of doing 3 things over and over again:

First, you take a small upcoming change to the system, like a user story, and have a conversation to explore, discover and agree on the desired behavior of the system, by using concrete examples.
Then, we document those examples in a way that could be automated and check for agreement.
Finally, we get to code and implement the behavior described by each documented example, starting with a failing automated test that will guide the development.

These 3 practices/phases are called Discovery, Formulation, and Automation.

Discovery (What it could do)

Documentation and automated tests are nice side-effects of BDD.
The real goal is valuable, working software.
The fastest way to get there is through conversations between the people involved in imagining and delivering the software.
Have the right conversations at the right time.
Minimize the amount of time spent in meetings & maximize the amount of valuable code you produce.

Discovery workshops

Note: You may think you are already doing this, through backlog grooming, refinement, planning poker sessions, or similar meetings depending upon your Agile framework, but those are not enough. Techniques like Example Mapping, OOPSI Mapping (Outcomes, Outputs, Processes, Scenarios, Inputs) and Feature Mapping are much more efficient, shorter and productive to help build this shared understanding.

Formulation (What it should do)

We can now formulate each example as structured documentation.
We use a medium (ie Gherkin) that can be read by both humans and computers
Get feedback from the whole team about our shared vision
We’ll be able to automate these examples to guide our development of the implementation.

Gherkin example

Automation (What it actually does)

Now, we can use our executable specifications to guide our development.
Taking one example at a time, we automate it by connecting it to the system as a test.
The test fails because we have not implemented the Behavior it describes yet.
We develop the implementation code, using lower-level examples of the Behavior of internal system components to guide us as required (micro-tests or unit-tests).

For the automation phase, we make use of automation tools that can understand the specification language and transform it into automated specifications.

With this, developers can then use this automated specification to guide the application development. Some of these tools are Cucumber, JBehave, Behat, and Specflow, among others. These tools allow mapping specific lines from each scenario to an instruction that will execute it in the app. These mappings are called Step definitions, which can be explored in more detail here.

There’s often some confusion as to who should write the Gherkin scenarios and who should write the step definitions (This is a good explanation of this topic). However, as recommended by Cucumber guys, as the team is building the shared understanding and ubiquitous language, the Product Owner/Manager should be involved in the writing of the Gherkin scenarios along with a developer and a tester.

After the team is confident with the understanding of the domain language, they can start doing the scenarios themselves without the Product person, and just do a sanity check after they are done to confirm we have captured the examples correctly in the formulated documentation.

The whole BDD process

Image taken from: https://youtu.be/cq_3wPnaX-w

As you can see, each phase has an objective and outputs that power the next phase. So, for the Discovery phase, we want to explore and discuss how the system should behave, and the outcome of it is an agreed behavior of the system through concrete examples.

Next, for the Formulation phase, we grab those concrete examples from the discovery phase and we formulate them in a way that can be automated, which has the outcome of a set of documented examples and acceptance tests.

Finally, in the Automation phase, we do the coding as per the documented examples, to implement agreed system behavior. However, we do this by first creating an automated test (taking one example at a time) to guide the development.

Living Documentation

Over time, the documented examples become an asset that enables the team to continue confidently and rapidly making changes to the system. This is called Living Documentation because:

The code reflects the documentation.
The documentation reflects the team’s shared understanding of what the code does.

This shared understanding and the living documentation are constantly evolving and are kept up to date with the actual system Behavior, as the implementation is guided by them. What this means is that the documentation (the formulated gherkin scenarios) is always up to date with what the system does; And if we have automated this documentation, using a tool like Cucumber, we would know very fast when something is not working as expected, since the automated tests would instantly fail if the system does not behave as the formulated Gherkin scenarios describe.

So, these formulated scenarios act as the single source of truth for all teams to have a shared understanding of how the system should behave, and for any new team member or external person to easily grasp how the system currently behaves, without having to dig into the source code or out of date documentation/Jira tickets.

Furthermore, several tools can automatically generate a beautiful documentation web page based on those scenarios and will generate useful reports on the automated runs. You can check what Serenity BDD does, for example.

Conclusion

We have seen what BDD is, the phases it consists of, and how it supports Agile methodologies.

Of course, BDD has a learning curve for development teams. Although defect rates will drop substantially very early in the process, productivity often suffers as the team gets the hang of it (A nice article about BDD adoption, tips and useful metrics to keep track can be found here, which in itself links to other very useful resources).

I recommend you buy and read the [BDD Books](http://www.bddbooks.com/). They are great resources to learn and start applying and maturing BDD techniques in your teams, based on two well-known BDD experts’ experiences.

Note: The full article is available in my personal blog. If you are interested in more details about how BDD works and how it fits into an agile workflow, feel free to check it out at: https://marcs.hashnode.dev/introduction-to-Behavior-driven-development-bdd

References: